image

VR-Forces


image

image

Users Guide


image

VR-Forces


image

Users Guide


image


Copyright © 2017 VT MAK

All rights Reserved. Printed in the United States.

Under copyright laws, no part of this document may be copied or reproduced in any form without prior written consent of VT MAK.

VR-Exchange™, VR-TheWorld™, VR-Vantage™, DI-Guy™, and DI-Guy Scenario™ are trademarks of VT MAK. MÄK Technologies®, VR-Forces®, RTIspy®, B-HAVE®, and VR-Link® are registered trademarks of VT MAK.

Terrain Profiles are based in part on the work of the Qwt project (http://qwt.source- forge.net).

All other trademarks are owned by their respective companies.

For third-party license information, please see “Third Party Licenses,” on page lviii.


VT MAK

150 Cambridge Park Drive, 3rd Floor Cambridge, MA 02140 USA


Voice: 617-876-8085

Fax: 617-876-9208


info@mak.com www.mak.com

Revision VRF-4.5-1-170217


image

Contents


image

Preface


How This Manual is Organized ............................................................. xlvii

VR-Forces Documentation................................................................. liii

MAK Products .......................................................................................... liii

How to Contact Us ................................................................................... lvi

Document Conventions ........................................................................... lvii

Mouse Button Naming Conventions................................................ lviii Third Party Licenses ................................................................................ lviii

Boost License.................................................................................... lviii

libXML and libICONV ..................................................................... lix Lua..................................................................................................... lix Freefont OpenType Font Set.............................................................. lix NVIDIA.............................................................................................. lx

Third-Party Licenses for VR-Vantage Applications.............................. lx

Section I Introduction, Installation, and Startup

image

Chapter 1. Introduction to VR-Forces

    1. Overview 1-3

      1. Entity-Level and Aggregate-Level Simulation 1-5

      2. Realistic Display of Vehicles and Terrain (3D View) 1-7

      3. Create Complex Scenarios 1-7

      4. Simulation Object Types Supported 1-8

      5. Mission Planning 1-10

      6. Simulation Object Tasks 1-10

      7. Scripted Tasks and Set Data Requests 1-11

      8. Tactical Graphics 1-11

      9. Terrain Agility and Composability 1-12

      10. Crowd Behaviors and Pattern of Life 1-12

      11. Flexible, Intuitive Graphical User Interface 1-13

      12. Overlays 1-13

      13. Behaviors 1-13

      14. Observer Attach Modes 1-14

      15. Special Effects and Simulation Object Information

        Visualization 1-14

      16. Dynamic Ocean 1-14

      17. Lighting Effects 1-15

      18. Accurate Vehicle Positioning 1-15

      19. Batch Mode Operation 1-15

      20. Remote Control 1-16

    2. The VR-Forces Toolkit 1-16

      1. Plug-in Architecture 1-16

1.3. DI-Guy 1-17

    1. Support for External Communications Servers 1-17

    2. Helpful Utilities 1-18

    3. Third-Party Software and Content 1-19

      1. SilverLining 1-19

      2. Triton Ocean SDK 1-20

      3. GL Studio 1-20

      4. SpeedTree 1-21

      5. 3D Models, Terrain, and Graphical Content 1-21

      6. OpenSceneGraph 1-22

      7. osgEarth 1-22

    4. Distributed Simulation Standards Supported 1-22

image

Chapter 2. Installing VR-Forces

    1. Installing VR-Forces 2-2

      1. Installing VR-Forces on Windows 2-2

      2. Installing VR-Forces on a Linux System 2-3

      3. Uninstalling VR-Forces 2-3

    2. The VR-Forces Directory Structure 2-4

    3. Installing and Setting Up the MAK License Manager 2-5

      1. Specifying the License Server 2-6

    4. Installing an RTI 2-8

      1. Installing the MAK RTI 2-9

    5. Localizing the Graphical User Interface 2-10

      1. Translating Other Interface Files 2-13

      2. Translating VR-Forces Scripts and Console Messages 2-14

      3. Applying the Language Files 2-15

      4. Merging Translation Files 2-15

image

Chapter 3. VR-Forces Application Concepts

    1. The VR-Forces Program 3-2

    2. Front-end and Back-end Concepts 3-2

      1. How Front-ends and Back-ends Work Together 3-3

      2. How VR-Forces Back-ends are Identified 3-4

      3. VR-Forces Sessions 3-4

      4. Coordinating Multiple Front-ends 3-6

      5. Working with Multiple Back-ends 3-7

    3. Objects 3-8

      1. The Object Parameter Database 3-8

      2. Local Objects and Remote Objects 3-9

    4. Representing and Managing Time in VR-Forces 3-10

      1. Simulation Time 3-10

      2. Time of Day 3-10

      3. Exercise Clock Modes 3-11

    5. Interactions 3-12

    6. Advanced Terrain Navigation 3-12

      1. How Navigation Data is Generated 3-12

      2. Path Finding 3-14

image

Chapter 4. Starting VR-Forces

    1. Starting VR-Forces 4-3

      1. Starting VR-Forces from the VR-Forces Launcher 4-3

      2. Starting Independent VR-Forces Executables 4-8

      3. Specifying a Session ID 4-8

      4. VR-Forces Startup Tutorial 4-9

    2. The VR-Forces Window 4-11

      1. Opening New Windows 4-13

      2. Printing the VR-Forces Display 4-13

    3. Managing a Front-end’s Session Connection 4-14

      1. Joining a Session 4-15

      2. Resigning from a Session 4-15

      3. Configuring Session Messages and Join at Startup 4-16

    4. Using HLA Time Management 4-17

      1. VR-Forces Simulation Time Versus Federation Time 4-18

      2. Configuring Time Management for HLA Exercises 4-18

    5. Opening a Terrain Database 4-19

      1. Loading a Terrain Database at Startup 4-21

      2. Closing a Terrain 4-21

    6. Managing VR-Forces Settings 4-21

      1. Synchronizing Settings Among VR-Forces Installations 4-23

      2. Global Settings and Observer-Specific Settings 4-24

    7. Exiting VR-Forces 4-24

    8. Configuring Simulation Connections 4-24

      1. Opening the Simulation Connections Configuration

        Dialog Box 4-25

      2. Adding a Simulation Connection 4-26

      3. Editing a Simulation Connection 4-27

      4. Simulation Connection Parameters 4-28

      5. Deleting a Simulation Connection 4-30

      6. Configuring Auto Connect 4-30

      7. Displaying Connection Information 4-31

    9. Managing Plug-ins 4-31

      1. Loading Plug-ins 4-32

      2. Adding a Plug-in 4-34

      3. Specifying the DLLs for a Plug-in 4-35

      4. Adding a Plug-in Configuration 4-36

      5. Deleting a Plug-in Configuration 4-36

      6. Deleting a Plug-in 4-37

      7. Viewing a List of Loaded Plug-ins 4-37

    10. The VR-Forces Log Files 4-38

image

Chapter 5. Command-line Options

    1. Command-Line Options for vrfGui 5-3

    2. Command-line Options for vrfSim 5-9

    3. Command-line Options for vrfLauncher 5-14

      1. Running in Combined Mode from the Command Line 5-15

      2. Using the -- Command-line Argument 5-15

    4. Protocol-Independent Command-line Options 5-15

      1. Specifying the Site ID and Application Number 5-15

      2. Specifying the Language to Use in the GUI 5-16

      3. Setting the Notification Level 5-16

      4. Loading Plug-ins 5-17

    5. Command-line Options for HLA Federations 5-17

      1. Specifying the Federation Execution 5-17

      2. Specifying the FED File 5-18

      3. Specifying the RPR FOM Version 5-18

      4. Specifying a FOM Mapper 5-18

      5. Specifying the RPR FOM Revision 5-18

      6. Specifying FOM Mapper Initialization Data 5-19

      7. Specifying a FED File That is Appropriate for the

        FOM Mapper 5-19

      8. Enabling Time Management 5-19

    6. Command-line Options for DIS Exercises 5-20

      1. Specifying the Port Number 5-20

      2. Specifying Point-to-Point or Multicast Operation 5-20

      3. Specifying the Multicast Time-to-Live 5-20

      4. Using Asynchronous I/O 5-20

      5. Specifying the Exercise ID 5-21

      6. Specifying the DIS Version 5-21

image

Chapter 6. Optimizing Performance

    1. Introduction 6-3

      1. Optimizing Simulation Engine Performance 6-3

      2. Optimizing Front-End Performance 6-4

    2. Monitoring the Back-end Frame Rate 6-5

    3. Displaying Performance Statistics 6-6

      1. Displaying the VR-Forces Function Profiler 6-8

      2. Displaying OSG Statistics 6-8

    4. Filtering Simulation Objects Using Interest Management 6-8

      1. Enabling Interest Management 6-9

      2. Configuring Interest Management 6-9

    5. Clearing the Model Instancing Cache 6-11

    6. Miscellaneous Performance Configuration Options 6-12

      1. Limiting Use of Spot Reports 6-12

      2. Using Asynchronous I/O for DIS Exercises 6-12

      3. Using Incremental Compiling with Streamed Data 6-12

    7. Setting the Tick Rate 6-13

      1. Specifying the Tick Rate for Components 6-13

      2. Tuning the Network Interface 6-14

      3. Tuning the State Repository Tick Rate 6-14

    8. Configuring Graphics Quality 6-14

    9. Balancing Visual Quality Against Network Performance 6-15

      1. Enabling Configuration of Performance Options 6-16

    10. Trajectory Smoothing 6-16

      1. Configuring Trajectory Smoothing 6-17

    11. Tuning the Target Frame Rate 6-17

    12. Coloring Draw Calls 6-18

    13. Configuring VSync 6-19

    14. DI-Guy Performance Settings 6-19

Section II Scenarios

image

Chapter 7. Creating and Running Scenarios

    1. Creating a Scenario 7-3

      1. Specifying Multiple Simulation Model Sets 7-8

      2. Creating Simulation Model Set Configurations 7-9

      3. Setting the Scenario Starting Date and Time 7-11

      4. Importing (Merging) Scenarios 7-12

      5. Importing and Exporting MSDL 7-14

      6. Scenario Building Blocks 7-16

    2. Loading a Scenario 7-17

      1. Loading a Recently Loaded Scenario 7-18

      2. Loading a Scenario from the Command Line 7-18

      3. Load Balancing a Scenario 7-19

      4. Displaying Scenario Information 7-21

      5. Editing the Scenario Description 7-23

      6. Sample Scenarios 7-23

    3. Running a Scenario 7-24

      1. Changing the Simulation Speed 7-24

      2. Pausing a Scenario 7-25

      3. Rewinding a Scenario 7-25

      4. Closing a Scenario 7-27

    4. Saving a Scenario 7-27

      1. Saving a Previously Saved Scenario 7-29

      2. Saving a Scenario to a New Name or a Different Format 7-29

    5. Checkpoints and Snapshots 7-30

      1. Saving Checkpoints 7-30

      2. Deleting Checkpoints 7-33

      3. Creating Snapshots 7-33

      4. Clearing the Snapshot List 7-34

    6. Pausing a Scenario Automatically 7-35

      1. Setting the Scenario End Time for a New Scenario 7-35

      2. Setting the Scenario End Time for an Open Scenario 7-35

    7. Running VR-Forces in Batch Mode 7-36

      1. The Batch File 7-36

      2. Creating a Batch File 7-37

      3. Editing a Batch File 7-37

      4. Running VR-Forces in Batch Mode 7-39

      5. Recording Batch Scenarios 7-40

    8. Sending Run and Pause Messages to Simulation Participants 7-41

    9. Recording VR-Forces Simulations with the MAK Data Logger 7-41

image

Chapter 8. Scenario Events

    1. Introduction to Scenario Events 8-2

    2. Creating a Scenario Event 8-3

      1. Adding Content to a Scenario Event 8-5

      2. Adding Linked Events 8-6

    3. Adding Intelligence Objects 8-8

    4. Starting a Scenario Event 8-10

      1. Starting a Scenario Event from a Plan 8-11

    5. Ending a Scenario Event 8-12

    6. Sorting the Event List 8-13

    7. Deleting a Scenario Event 8-13

    8. Showing and Hiding Scenario Events 8-14

image

Chapter 9. Target Detection and Combat Features

    1. Displaying Simulation Objects Based on Spot Reports 9-2

      1. Enabling or Disabling Spot Reports 9-3

      2. Configuring the Spot Reports Viewpoint 9-4

      3. Configuring the Spot Reports Certainty Level 9-8

      4. Applying Spot Reports to Tactical Graphics 9-9

      5. Displaying Labels for Spot Reports 9-9

      6. Using Spot Reports in Tasks 9-9

    2. Managing Force Hostility Relationships 9-10

      1. Changing a Force’s Hostility in a Plan 9-12

    3. Detecting Targets 9-13

      1. Target Detection and Spot Reports 9-15

      2. Lasing Targets 9-15

    4. Using Sonar 9-17

      1. Propulsion Noise and Sonar 9-18

    5. Launching Counter Measures (Chaff and Flare) 9-19

    6. Modeling Artillery Munitions 9-21

image

Chapter 10. Indirect Fire, Ballistic Missiles, and Munition Detonations

    1. Introduction to Indirect Fire 10-2

      1. Creating an Indirect Fire Event 10-3

      2. Editing Indirect Fire Events 10-6

      3. Deleting Indirect Fire Events 10-6

      4. Configuring Indirect Fire Event Default Values 10-7

    2. Ballistic Missiles 10-8

      1. Firing Ballistic Missiles 10-8

      2. Editing Missile Target Events 10-10

      3. Deleting Missile Target Events 10-10

    3. Creating Munition Detonations 10-11

image

Chapter 11. Setting Environment Conditions

    1. Introduction to Environment Conditions 11-2

    2. Setting the Date and Time of Day 11-2

      1. Setting the Date 11-3

      2. Setting the Time of Day 11-4

      3. Choosing the Illumination Model 11-4

    3. Specifying the Environment Conditions 11-5

      1. Adding an Environment Condition 11-7

      2. Editing an Environment Condition 11-7

      3. Deleting an Environment Condition 11-8

    4. Setting Weather Conditions 11-8

      1. Setting the Wind Speed and Direction 11-9

      2. Setting the Ambient Air Temperature 11-10

      3. Setting Visibility (Fog) 11-10

      4. Specifying Precipitation Type and Intensity 11-12

      5. Specifying Cloud Cover 11-12

    5. Creating Local Weather Zones 11-13

      1. Editing a Weather Zone’s Environment 11-15

    6. Configuring Marine Conditions 11-16

      1. Enabling Marine Effects 11-17

      2. Configuring Marine Conditions 11-17

      3. Enabling Tidal Stream Wakes 11-19

      4. Setting Ocean Quality 11-20

      5. Configuring Breaking Waves 11-21

    7. Setting the Thermocline 11-22

image

Chapter 12. Scenario Files

    1. Introduction 12-2

    2. The Scenario File 12-3

      1. Scenario Parameters 12-4

      2. Specifying Pathnames for Scenario Files 12-7

      3. Changing the Terrain Database for a Scenario 12-8

    3. The Plan File 12-8

    4. The Object Map File 12-9

    5. Editing the Order of Battle File 12-10

      1. Saving Default Parameters to the Order of Battle File 12-10

    6. The Scenario Extras File 12-10

    7. Temporary Scenario Directories 12-11

image

Chapter 13. Using a Communications Effects Server

    1. Introduction 13-2

    2. Configuring VR-Forces 13-2

      1. Enabling the External Communication Model 13-3

      2. Configuring the External Communication Model 13-3

image

Chapter 14. Example Entity-Level Scenarios

    1. The Breaching Scenario 14-2

      1. Create the Scenario 14-3

      2. Create the Minefield 14-4

      3. Create the Opposing Forces 14-5

      4. Create the Tactical Graphics 14-7

      5. Create the Friendly Simulation Objects 14-9

      6. Write the Plans 14-10

      7. Save the Scenario 14-20

      8. Running the Scenario 14-21

    2. The Embarkexample Scenario 14-22

      1. Create the Simulation Objects 14-23

      2. Create the Tactical Graphics 14-26

      3. Write the Plans for the Entities 14-28

Section III Simulation Objects

image

Chapter 15. Introduction to Simulation Objects

    1. Simulation Objects 15-2

    2. How Simulation Objects are Identified 15-3

      1. UUIDs 15-3

      2. Simulation Object Names 15-4

      3. Echelon IDs 15-4

      4. Object IDs 15-4

      5. Labels 15-5

    3. How Simulation Objects are Organized 15-6

      1. How Echelon IDs are Assigned 15-7

    4. How Simulation Objects Communicate 15-7

      1. External Communication Model 15-7

      2. Custom Communication Models 15-8

    5. VR-Forces Uses a Component Architecture 15-8

      1. Sensors 15-9

      2. Controllers 15-9

      3. Actuators 15-9

    6. Simulation Object Behaviors and Tasks 15-10

    7. Entity-Level Modeling and Aggregate-Level Modeling 15-10

image

Chapter 16. Creating and Placing Objects

    1. Creating Objects 16-3

    2. Selecting the Object to Create 16-4

      1. Selecting the Object to Create on an Object Palette 16-5

      2. Selecting the Object to Create on the Create Menu 16-8

      3. Draw Mode 16-9

    3. Placing Objects 16-11

      1. Placing an Object Using Default Values (Click to

        Create) 16-11

      2. Specifying an Object’s Properties Before You Create It

        (Click to Locate) 16-13

    4. Specifying an Object’s Altitude 16-14

      1. Setting Altitude Dynamically 16-15

      2. Setting Altitude in the Create Object or Edit Object

        Dialog Box 16-15

      3. Specifying the Altitude for All of the Vertices in a Route .. 16-16

    5. Specifying an Object’s Heading Dynamically 16-17

    6. Locking the Mouse to the Object Being Created 16-18

    7. Moving Objects 16-19

      1. Dragging an Object to a New Location 16-19

    8. Copying and Pasting Objects 16-21

      1. Copying Objects 16-21

      2. Pasting Objects 16-22

      3. Pasting Specific Entity Characteristics 16-23

    9. Simulation Object Groups 16-25

    10. Creating Random Versions of Similar Entity Types 16-25

    11. Creating Cultural Features 16-26

    12. Creating Props 16-26

    13. Adding an Object to the Favorites List 16-27

image

Chapter 17. Selecting Objects

    1. The Objects List Panel 17-2

    2. Selecting Simulation Objects, Tactical Graphics, and Props 17-4

      1. Selecting Objects in the Window 17-5

      2. Selecting Objects in the Objects List Panel 17-6

      3. Selecting a Simulation Object in the Object Console

        Summary Panel 17-6

      4. Unselecting Objects 17-7

    3. Using Selection Groups 17-7

      1. Creating a Selection Group 17-8

      2. Selecting a Selection Group 17-9

      3. Adding Objects to a Selection Group 17-10

      4. Removing Objects from Selection Groups 17-10

      5. Renaming a Selection Group 17-10

      6. Deleting a Selection Group 17-10

image

Chapter 18. Viewing Information about Objects

    1. Displaying Information About an Object 18-3

      1. Information Dialog Boxes for Entity-Level Scenarios 18-3

      2. Information Dialog Boxes for Aggregate-Level Scenarios 18-6

      3. Information Dialog Boxes for Tactical Graphics 18-8

      4. Viewing Information for Multiple Objects 18-9

    2. Displaying Entity Labels 18-9

      1. Displaying Text Labels for 3D Models 18-12

      2. Turning Entity Labels On and Off 18-13

      3. Pinning 3D Text Labels to the Window 18-13

      4. Displaying Labels for 2D Icons 18-14

      5. Configuring Shadowing and Background Color for

        2D Labels 18-16

    3. Using Extended Labels 18-17

      1. Adding an Extended Label 18-18

      2. Changing an Extended Label’s Index 18-19

      3. Deleting an Extended Label 18-19

    4. Simulation Object Icons 18-20

      1. Changing the Size of 2D Icons 18-21

      2. Rotating 2D Icons to a Simulation Object’s Heading 18-22

    5. Displaying HAT Lines for Entities (3D Only) 18-23

    6. Displaying Threat and Sensor Range Rings 18-24

      1. Enabling and Disabling the Display of Range Rings 18-26

      2. Pinning Range Rings for a Simulation Object 18-26

      3. Configuring the Display of Range Rings 18-27

    7. Displaying Entity Resources 18-29

      1. Viewing Numerical Resource Data 18-29

    8. Displaying Bounding Volumes 18-30

      1. Showing Bounding Volumes Only for Selected

        Simulation Objects 18-31

    9. Configuring Object Console Messages 18-31

      1. Setting the Notification Level for Console Messages 18-32

      2. Viewing All Console Messages 18-33

      3. Answering Questions from Scripted Tasks 18-34

      4. Saving Console Messages 18-35

      5. Displaying an Object Console Warning Icon 18-35

      6. Clearing the Object Console 18-35

    10. Viewing Object Counts 18-36

image

Chapter 19. Creating Simulation Objects

    1. Creating Simulation Objects 19-3

      1. Default Placement of New Entities 19-3

      2. Placing Entities Inside Buildings 19-4

      3. Placing Simulation Objects on Other Simulation Objects .. 19-4 19.1.4. Simulation Object Resources 19-4

        19.1.5. Deleting Simulation Objects 19-5

    2. Editing Simulation Objects 19-5

    3. Embarking and Disembarking Simulation Objects 19-7

      1. Embarking and Disembarking Simulation

        Objects Instantly 19-8

      2. Disembarking Simulation Objects Using the

        Disembark Command 19-11

    4. Embedded Entities 19-12

      1. Configuring an Entity to Support Embedded Entities 19-13

      2. Assigning Tasks and Plans to Embedded Entities 19-15

      3. Restoring an Entity that has Embedded Entities 19-15

    5. Collision, Obstacle, and Feature Avoidance 19-16

    6. Entity Movement and Soil Type 19-17

    7. Using a Joystick to Control Entities 19-18

      1. Switching Between Systems 19-19

      2. Disabling Joystick Control 19-20

    8. Using the Keyboard to Control an Entity 19-20

    9. Using Ground Clamping 19-20

      1. Configuring Ground Clamping 19-22

    10. Exaggerating the Scale of 3D Entity Models 19-23

    11. Hiding 3D Models 19-26

    12. Changing Force Colors 19-26

image

Chapter 20. Generating Traffic (Pattern of Life)

    1. Generating Traffic 20-2

    2. Creating Spawn Points 20-2

    3. Creating Sink Points 20-4

    4. Spawn Patterns 20-5

      1. How Spawn Events are Scheduled 20-6

      2. Spawning Entities in Bursts 20-8

      3. Using a Custom Plan 20-9

      4. Default Spawn Patterns and Scenario-Specific Patterns 20-9

    5. Creating a Spawn Pattern 20-10

      1. Copying a Spawn Pattern 20-14

    6. Editing a Spawn Pattern 20-15

    7. Deleting a Spawn Pattern 20-16

image

Chapter 21. Crowds and Multiple Simulation Objects

    1. Creating Multiple Simulation Objects and Crowds 21-2

    2. Creating Crowds Using a Pedestrian Area 21-2

      1. Adding Entities to a Pedestrian Area 21-3

    3. Creating Crowd Units 21-3

      1. Crowd Tasks 21-4

    4. Creating Multiple Simulation Objects 21-5

      1. Adding an Area for Multiple Simulation Object Creation .. 21-8

      2. Specifying the Simulation Objects to Create 21-8

    5. Pedestrian-Oriented Tactical Graphics 21-9

      1. Using Civilian Visit Points 21-10

Section IV Modeling Units

image

Chapter 22. Entity-Level Unit Modeling

    1. Units in Entity-Level Scenarios 22-2

      1. How Units Are Organized 22-3

      2. How Units Move 22-4

      3. How Units Carry Out Tasks 22-5

image

Chapter 23. How Aggregate-Level Modeling Works

    1. The Aggregate Warfare Model 23-2

      1. Unit Combat 23-3

      2. Unit Footprints 23-4

      3. Unit Posture 23-4

      4. Unit Movement 23-6

      5. Limited Munition Attack 23-7

      6. Contamination Areas 23-7

      7. Unit Sensors 23-8

    2. Combat Engineering Objects 23-9

      1. Concealed Obstacles 23-11

      2. Creating Combat Engineering Objects 23-11

      3. How Engineering Units Create Engineering Objects 23-12

    3. Logistics 23-13

      1. Receiving Supplies 23-15

      2. Providing Supplies 23-15

    4. Electronic Warfare 23-16

      1. Jamming Communications 23-16

      2. Jamming Radar 23-17

      3. Sensing Electronic Emissions 23-18

image

Chapter 24. Creating and Controlling Units

    1. Creating Units 24-2

      1. Creating a Unit by Combining Existing Simulation

        Objects 24-2

      2. Creating a Preconfigured Unit 24-5

      3. Configuring the Unit Creation State 24-6

    2. Selecting a Unit 24-6

    3. Adding Simulation Objects to a Unit 24-7

    4. Removing a Simulation Object from a Unit 24-8

    5. Units and Unit State in Entity-Level Scenarios 24-8

      1. How a Unit’s State is Shown 24-9

      2. How Changing Aggregation State Affects a Unit 24-10

    6. Triggering Unit State Transitions 24-11

      1. Aggregating and Disaggregating Units Manually 24-12

      2. Configuring Automatic Aggregation and Disaggregation .. 24-12 24.6.3. Using Disaggregation Areas 24-12

    7. Writing Plans for Units 24-12

    8. Deleting a Unit 24-13

image

Chapter 25. Displaying Units

    1. Selecting Units 25-2

    2. Expanding and Collapsing Units 25-2

      1. Expanding and Collapsing Units in the Echelon View 25-4

      2. Expanding and Collapsing the Echelon View by

        Level of Aggregation 25-4

    3. Displaying Ghosted Icons 25-6

    4. Displaying Unit Icons and Bounding Volumes 25-9

      1. Specifying the Color Scheme for Unit BoundingVolumes 25-11

Section V Tasks and Sets

    1. Introduction to Tasks 25-1

    2. Introduction to Set Data Requests 25-2

Chapter 26. Assigning Tasks

image

    1. Assigning Tasks to Simulation Objects 26-3

      1. Task Procedures 26-3

      2. C++ Tasks and Scripted Tasks 26-4

      3. Concurrent Task Execution 26-5

      4. How do I Know which Simulation Object can

        Execute a Task? 26-7

      5. Escaping the Task Assignment Process 26-7

      6. Specifying Parameters for Tasks 26-7

      7. Viewing Task Status 26-9

      8. Filtering the Object Selection Lists 26-10

      9. Skipping (Stopping) a Task 26-10

    2. Assigning Tasks to Units 26-11

      1. Convoy Tasks 26-11

      2. Independently Tasking Unit Members 26-12

    3. Reactive Tasks 26-12

      1. Enabling Reactive Tasks 26-14


      2. Disabling Reactive Tasks 26-15

      3. Setting the Priority of a Reactive Task 26-16

      4. Managing Reactive Tasks 26-17

      5. Canceling a Reactive Task 26-18

    4. Using Behavior Sets to Manage Scripts 26-19

      1. Creating Behavior Sets 26-20

      2. Editing Behavior Sets 26-21

      3. Assigning a Behavior Set to a Force 26-21

    5. Entity Movement On Roads and Off Roads 26-22

      1. Road Driving Behavior 26-23

    6. Fixed-Wing Entity Tasks and Behaviors 26-23

      1. Placement of Newly Created Fixed-Wing Entities 26-23

      2. Fly Task Behavior is Different from Move Task

        Behavior 26-24

      3. Specifying and Maintaining Altitude for

        Fixed-Wing Entities 26-25

      4. Fixed-Wing Entity Movement on the Ground

        and in the Air 26-26

      5. How Fixed-Wing Entities Take Off 26-28

      6. How Fixed-Wing Entities Land 26-29

    7. Rotary-Wing Entity Tasks and Behaviors 26-30

      1. Controlling Rotary-Wing Orientation 26-32

    8. Suppressive Fire Tasks 26-32

      1. Configuring Suppression Effects 26-34

    9. Configuring Task Execution Rules 26-35

      1. Configuring Action Categories 26-36

image

Chapter 27. Movement Tasks for Entity-Level Scenarios

    1. Animated Movement 27-3

    2. Come to Stop 27-4

    3. Convoy Along 27-4

    4. Convoy To 27-5

    5. Fast Rope Insertion 27-6

    6. Fixed-Wing Land 27-7

    7. Fixed Wing Takeoff 27-8

    8. Fly Altitude 27-8

    9. Fly Heading 27-9

    10. Fly Heading and Altitude 27-10

    11. Follow Entity 27-11

      1. How Fixed-Wing Entities Follow Entities 27-11

    12. Generate Air Traffic From Flight Plans 27-12

    13. Land at Airport Near Location 27-12

    14. Move Along Route 27-13

    15. Move Into Formation 27-14

    16. Move to Altitude 27-15

    17. Move to Depth 27-15

    18. Move to Location 27-16

      1. Adding Multiple Move to Location Tasks to a Plan 27-17

    19. Move to Location (Plan Along Roads) 27-18

    20. Move to Location (Plan Path) 27-19

    21. Move to Waypoint 27-20

    22. Move to Waypoint (Plan Along Roads) 27-21

    23. Move to Waypoint (Plan Path) 27-22

27.24. Orbit 27-23

    1. Patrol Route 27-23

    2. Patrol Between 27-24

    3. Pattern Hold (Location) 27-24

    4. Pattern Hold (Waypoint) 27-25

    5. Rotary Wing Airlift Cargo to Location 27-25

    6. Rotary Wing Land 27-26

    7. Rotary Wing Retrieve Cargo 27-26

    8. Rotary Wing Unload Cargo 27-27

    9. Sail Heading 27-27

    10. Turn to Heading 27-28

image

Chapter 28. Engagement Tasks for Entity-Level Scenarios

    1. Arm Mine at Depth 28-3

    2. Attack Aircraft with Guns 28-3

    3. Drop Naval Depth Charge 28-4

    4. Drop Naval Depth Charge at Location 28-4

    5. Drop Naval Mine 28-5

    6. Drop Naval Mines Along Route 28-6

    7. Execute Close Air Support 28-7

    8. Explode Charge at Depth 28-9

    9. Fire at Target 28-9

    10. Fire Cruise Missile 28-10

    11. Fire for Effect Tasks 28-11

      1. Firing Naval Guns 28-12

    12. Lase Target 28-12

    13. Launch Anti-Submarine Missile (Vertical) 28-12

    14. Launch Counter Measures 28-13

    15. Launch Smoke 28-13

    16. Launch Torpedo 28-14

      1. Anti-ship (Fixed Depth) 28-14

      2. Anti-Submarine 28-15

    17. Place IED 28-16

    18. Provide Suppressive Fire 28-17

    19. Provide Suppressive Fire at Location 28-18

    20. Release Bomb Tasks 28-18

    21. Sector Search Operation 28-20

    22. Strafe Ground Target 28-21

    23. Sweep Naval Mines 28-23

    24. Throw Grenade Tasks 28-23

      1. Throw Grenade at Location 28-23

      2. Throw Grenade at Target 28-24

image

Chapter 29. Human and Crowd Tasks

    1. Civilian Idle 29-2

    2. Close Door 29-2

    3. Close Window 29-2

    4. Create Pedestrians 29-3

    5. Crowd Along Line 29-3

    6. Crowd Around Location 29-4

    7. Crowd Around Object 29-4

    8. Crowd in Front of Entity 29-5

    9. DI-Guy Animation 29-5

    10. Disperse Crowd 29-5

    11. Flee from Entities 29-6

    12. Open Door 29-6

    13. Open Window 29-6

    14. Protest Around Location 29-7

    15. Protest Along Line 29-7

    16. Wander 29-7

    17. Wander In Area 29-8

image

Chapter 30. Embarkation, Wait, Radio, and Other Tasks

    1. Embarkation Tasks 30-3

      1. Disembark 30-3

      2. Disembark All 30-3

      3. Embark 30-4

    2. Radio Tasks 30-7

      1. Send Radio Set 30-7

      2. Send Radio Task 30-9

      3. Send Text Message 30-10

    3. Wait Tasks 30-10

      30.3.1. Wait 30-10

          1. Wait Duration 30-11

          2. Wait Elapsed 30-11

    4. Tasks for Moving Articulated Parts 30-11

      1. Close Cargo Door 30-11

      2. Deploy Refueling Boom 30-12

      3. Lower Periscope 30-12

      4. Open Cargo Door 30-13

      5. Raise Periscope 30-13

      6. Stow Refueling Boom 30-13

    5. Embedded Entity Tasks 30-14

      1. Deploying Embedded Entities 30-14

      2. Recovering Deployed Entities 30-14

      3. Sector Search Operation 30-15

      4. Deploying an Entity with a Task 30-16

    6. Deploy Sonobuoy 30-17

    7. Deploy Sonobuoys Along Route 30-17

    8. Sonar Dip 30-18

    9. User Task 30-18

    10. Reactive Tasks 30-19

image

Chapter 31. Tasks for Aggregate-Level Scenarios

    1. Introduction to Aggregate-Level Tasks 31-4

    2. Activate Jammer 31-4

    3. Air-to-Ground Attack 31-4

    4. Attack by Fire 31-5

    5. Attack with Anti-Air Missile 31-5

    6. Attack with Anti-Ship Missile 31-5

    7. Attack with Land-Attack Missile 31-6

    8. Attack with Torpedo 31-6

    9. Automatic Air Defense 31-6

    10. Biological Attack 31-7

    11. Bomb Location 31-8

    12. Breach Obstacles 31-9

    13. Change MOPP Level 31-10

    14. Change Posture 31-11

    15. Chemical Attack 31-11

    16. Construct Abatis 31-12

    17. Construct Anti-Tank Ditch 31-13

    18. Construct Barbed Wire 31-14

    19. Construct Barricade 31-14

    20. Construct Berm 31-15

    21. Construct Booby Trap 31-15

    22. Construct Bridge 31-16

    23. Construct Dry Gap 31-17

    24. Construct Fortified Area 31-18

    25. Construct Fortified Line 31-19

    26. Construct Minefield 31-20

    27. Construct Strong Point 31-21

    28. Deactivate Jammer 31-21

    29. Destroy Bridge 31-22

    30. Destroy Ditch 31-22

    31. Destroy Explosive 31-22

    32. Destroy Fortification 31-23

    33. Destroy Obstacle 31-23

    34. Disembark 31-23

    35. Disembark All 31-23

    36. Embark 31-23

    37. FASCAM 31-24

    38. Halt Movement 31-24

    39. Improve Booby Trap 31-24

    40. Improve Breach 31-25

    41. Improve Bridge 31-25

    42. Improve Ditch 31-25

    43. Improve Fortification 31-26

    44. Improve Obstacle 31-26

    45. Indirect Fire 31-27

    46. Move Along Route 31-28

    47. Move Along Route Retrograde 31-28

    48. Move to Location 31-28

    49. Move to Location Retrograde 31-28

    50. Move To Waypoint 31-28

    51. Move to Waypoint Retrograde 31-28

    52. Nuclear Attack 31-29

    53. Patrol Route 31-29

    54. Patrol Between 31-29

    55. Send NBC Report 31-29

    56. Send Obstacle Report 31-30

    57. Send Radio Set 31-30

    58. Send Radio Task 31-30

    59. Send Text Message 31-30

    60. User Task 31-30

    61. Wait Tasks 31-30

    62. Background Process List 31-31

image

Chapter 32. Creating Scripted Tasks and Sets

    1. Introduction to Scripts 32-3

      1. Scripted Tasks 32-4

      2. Scripted Sets 32-5

      3. Reactive Task Scripts 32-5

      4. Background Process Scripts 32-5

      5. Script Metadata 32-5

      6. The Lua Scripting Language 32-5

    2. Creating a New Script 32-6

      1. Specifying the Script ID 32-11

      2. Specifying a Menu Icon 32-11

      3. Specifying an Extended Name 32-12

      4. Specifying a Short Description 32-12

      5. Specifying Script Parameters 32-13

      6. Specifying a Menu Location 32-17

      7. Specifying Action Categories 32-18

      8. Configuring a Script’s Availability to a Simulation

        Object Type 32-19

      9. Specifying Equivalent Scripts for a Toolbar Button 32-23

      10. Specifying the Programming Language for a Script 32-25

      11. Creating Scripted Sets 32-26

      12. Creating Reactive Tasks 32-27

      13. Creating Background Processes 32-29

    3. Saving Scripts 32-30

    4. Editing a Script 32-30

    5. Filtering the List of Scripts 32-31

    6. Organizing Scripts into Folders 32-31

      1. Adding a Folder 32-31

      2. Renaming a Folder 32-31

      3. Deleting a Folder 32-32

      4. Adding Scripts to a Folder 32-32

      5. Removing a Script from a Folder 32-32

    7. Exporting and Importing Scripts 32-32

      1. Importing a Script Package 32-33

    8. Copying a Script 32-34

    9. Deleting a Script 32-34

    10. Creating a System Script 32-35

      1. Including System Scripts on the Task and Set Menus 32-35

    11. Specifying a Script Editor 32-37

    12. Editing Lua Files 32-38

image

Chapter 33. Writing Scripts

    1. The VR-Forces Lua Interface 33-3

      1. Lua Classes 33-3

      2. Lua Modules 33-6

    2. Script Loading and Execution 33-6

      1. Script Entry Points 33-7

      2. The Script Execution Sequence 33-9

      3. Limitations for Checkpointing Scripts 33-12

      4. Editing Scripts While a Scenario is Running 33-14

    3. Tasks and Subtasks 33-15

      1. Monitoring the Status of Tasks and Subtasks 33-16

      2. Stopping Tasks 33-16

      3. Task Parameters 33-16

    4. Geometry 33-18

      1. Location3D 33-18

      2. Vector3D 33-18

      3. VectorOffset3D 33-20

      4. VectorGeoc3D 33-20

    5. Coding Messages for Translation 33-21

    6. Error Detection 33-21

    7. Interactive Scripts 33-23

    8. A Basic Scripted Task 33-23

      1. Create and Move to Waypoint Metadata 33-24

      2. The Create and Move to Waypoint Lua Script 33-26

    9. A Simple Scripted Set 33-28

    10. A Simple Reactive Task 33-29

    11. Background Processes 33-30

image

Chapter 34. Setting the State of Simulation Objects

    1. Setting Simulation Object State and Attributes 34-4

    2. Active Sonar Mode 34-5

    3. Activity 34-6

    4. Aiming 34-7

    5. Altitude 34-8

    6. Ammunition 34-8

    7. Ammunition Pacing/Tracking 34-9

    8. Appearance 34-10

34.9. Armed 34-11

    1. Capabilities 34-11

    2. Collision Avoidance Types 34-12

    3. Concealed 34-13

    4. Contamination 34-13

    5. Counter Measures Auto Launch 34-13

    6. Current Speed 34-14

    7. Destroyed 34-14

    8. Detonation Fuse Type 34-15

    9. DI-Guy Characteristics (Appearance, Head, Body Weight) 34-16

    10. DI-Guy Hand Item 34-16

    11. Disembarked 34-17

    12. Embarked 34-17

    13. Emitter 34-18

    14. Engagement Results 34-19

    15. Equipment Pacing/Tracking 34-20

    16. Food, Water, Fuel, Oil and Lubricant 34-20

    17. Food, Water Fuel, Oil and Lubricant Pacing/Tracking 34-21

34.27. Force 34-21

    1. Formation 34-22

    2. Heading 34-23

    3. Health 34-23

34.31. IFF 34-24

    1. Invulnerable 34-25

    2. Jam Targets 34-25

    3. Lase Autonomous 34-25

    4. Laser Code 34-26

    5. Location 34-26

    6. MOPP Level 34-27

    7. Morale 34-27

    8. Navigation Preferences 34-28

    9. Notify Level 34-28

    10. Ordered Speed 34-29

    11. Percent Complete 34-29

    12. Posture (Unit) 34-30

    13. Posture (Human) 34-31

    14. Preferred Targets 34-32

    15. Radar Mode 34-33

    16. Reorganize 34-33

    17. Resources 34-34

    18. Resources Pacing/Tracking 34-34

    19. Restore 34-35

    20. Resupply Mode 34-35

    21. Rules of Engagement 34-36

      1. How Fire-When-Fired-Upon Works 34-36

    22. Sector of Responsibility 34-37

    23. Sensor Aim 34-38

    24. Sensor Enabled 34-38

    25. Sensor Zoom 34-39

    26. Sonar Depth 34-40

    27. Spot Reports 34-41

    28. Superior 34-42

    29. Supplying 34-42

    30. Surrendered 34-42

    31. Synchronize Laser Code 34-43

    32. Target 34-43

    33. Tasked by Superior 34-44

    34. Tracer Use 34-44

    35. Unit State 34-44

    36. Weapons Pacing/Tracking 34-45

Section VI Plans

VI.1. Introduction to Plans 34-1

Chapter 35. Plan Concepts

image

    1. Introduction to Individual Plans and Global Plans 35-2

    2. Conditional Statements 35-4

      1. The If Statement 35-6

      2. Triggers 35-7

      3. While Statements 35-9

      4. Wait Until Statements 35-9

      5. Conditional Tests 35-10

    3. Plan Variables 35-15

    4. Viewing Plans 35-16

    5. Considerations for Creating Plans 35-17

      1. Considerations for Using Triggers 35-17

      2. Using Concurrent Tasks in Plans 35-18

      3. Moving In Formation 35-18

      4. Using the Tasked-By-Superior Request in a Plan 35-18

      5. Following Simulation Objects 35-18


      6. Planning Tasks for Aircraft 35-19

      7. Using Non-VR-Forces Simulation Objects in Plans 35-19

image

Chapter 36. Writing Plans

    1. Writing Plans for Simulation Objects 36-3

      1. Adding a Task or Set Data Request to a Plan 36-4

      2. Adding an If Block to a Plan 36-5

      3. Adding a While Block to a Plan 36-6

      4. Adding a Wait Until Statement to a Plan 36-6

      5. Adding a Trigger to a Plan 36-7

      6. Registering Triggers 36-8

      7. Reregistering Triggers 36-9

      8. Unregistering Triggers 36-9

      9. Cleaning Up Unused Triggers 36-9

      10. Editing a Statement 36-9

      11. Deleting Statements from a Plan 36-10

    2. Printing Plans 36-10

    3. Saving Changes to a Plan 36-10

    4. Building Condition Statements 36-11

      1. Building a Condition Statement that has One

        Condition 36-11

      2. Building a Complex Condition 36-14

      3. Editing Condition Statements 36-21

      4. Specifying Names or Patterns in Condition Statements 36-22

    5. Using Plan Variables 36-25

    6. Creating Global Plans 36-26

      1. Controlling When Global Plans Run (Quick Launch) 36-28

      2. Opening an Information Dialog Box for a Global Plan 36-28

    7. Adding Commands to a Plan 36-29

      1. Adding Tasks and Sets from the Commands Menu 36-30

      2. Sending Console Messages 36-33

      3. Creating Objects from Within a Plan 36-33

      4. Deleting Objects from Within a Plan 36-33

      5. Issuing a Plan 36-34

      6. Sending View Control Messages 36-35

    8. Writing Plans for Units 36-39

    9. Writing a Plan for Multiple Simulation Objects 36-39

    10. Writing Plans for Remote Entities 36-39

    11. Copying Plans and Plan Statements 36-40

    12. Restarting a Plan 36-41

    13. Abandoning a Plan 36-42

Section VII Tactical Graphics

image

Chapter 37. Introduction to Tactical Graphics

    1. Introduction 37-2

    2. Points 37-4

    3. Phase Lines 37-4

    4. Routes 37-5

    5. Areas 37-5

    6. Obstacles 37-5

    7. Displaying Tactical Graphics 37-6

      1. Showing and Hiding Tactical Graphics 37-8

      2. Showing and Hiding Tactical Graphics Labels 37-9

      3. Displaying Height-Above-Terrain Lines for Vertices 37-10

image

Chapter 38. Overlays

    1. Creating and Editing Overlays 38-2

      1. Creating an Overlay 38-3

      2. Selecting Overlays 38-3

      3. Locking an Overlay 38-3

      4. Hiding the Objects on an Overlay 38-4

      5. Changing an Overlay’s Name 38-4

      6. Deleting an Overlay 38-5

    2. Saving and Loading Tactical Graphics and Overlays 38-5

      1. Loading Tactical Graphics and Overlays 38-5

    3. Exporting Tactical Graphics as Shapefiles 38-6

      1. Importing Shapefiles into Overlays 38-7

image

Chapter 39. Creating and Editing Tactical Graphics

    1. Creating Tactical Graphics 39-2

      1. Creating Freehand Lines 39-2

      2. Drawing Circles and Ellipses 39-3

      3. Drawing Boxes 39-3

      4. Creating Volumetric Tactical Graphics 39-4

      5. Adding Text to an Overlay 39-5

      6. Assigning Tactical Graphics to an Overlay 39-5

      7. Displaying a Terrain Profile When You Create a Line 39-6

      8. Publishing Tactical Graphics 39-7

      9. Creating a Computed Route 39-7

      10. Creating an Intel Collection Area 39-9

      11. Creating Routes for Aircraft 39-10

    2. Attaching Tactical Graphics to a Simulation Object 39-11

      1. Attaching a Tactical Graphic Automatically 39-11

    3. Deleting Tactical Graphics 39-11

    4. Editing Tactical Graphics 39-12

      1. Editing Vertices 39-13

      2. Resizing Boxes and Text Objects 39-15

      3. Rotating an Ellipse 39-16

      4. Changing the Direction of a Line 39-16

      5. Changing the Color of a Tactical Graphic 39-16

      6. Using the Force Color for Vertices 39-17

      7. Changing Linear and Areal Style Properties 39-17

    5. Active and Inactive Tactical Graphics 39-19

image

Chapter 40. Setting the State of Tactical Graphics

    1. Set Data Requests for Tactical Graphics 40-2

    2. Activation 40-3

    3. Allow Crossing 40-4

    4. Arrowhead Style 40-4

    5. Color 40-4

    6. Fill Style 40-5

    7. Force 40-5

    8. Line Width 40-5

    9. Notify Level 40-5

    10. Pen Style 40-6

image

Chapter 41. Remote Graphics

    1. Displaying Remote Graphics 41-2

      1. Viewing a List of Remote Graphics 41-4

Section VIII Visual and Audio Effects

image

Chapter 42. Displaying Tactical Information and Effects

    1. Displaying Trailing and Decal Effects (3D Only) 42-3

      1. Specifying Models for Trailing Effects and Decal Effects 42-4

    2. Displaying Track Histories 42-5

      1. Configuring Track Histories 42-6

      2. Displaying a Terrain Profile for a Track History 42-7

    3. Viewing Fire and Detonation Effects 42-8

    4. Viewing Fire and Detonation Lines 42-9

    5. Viewing Unit Combat Graphics 42-10

    6. Visualizing Tasks 42-12

      1. Pinning Task Visualizations for a Simulation Object 42-13

    7. Displaying Sensor Contact Lines 42-13

      1. Enabling the Display of Sensor Contact Lines 42-14

      2. Specifying which Simulation Objects Display Sensor

        Contact Lines 42-14

      3. Configuring Sensor Contact Lines 42-15

    8. Displaying Laser Designators 42-16

    9. Displaying Supply Lines 42-17

    10. Displaying Tactical Smoke 42-17

    11. Displaying Electromagnetic Emissions 42-18

    12. Displaying Radio Communication Lines 42-20

      1. Enabling Radio Communications Graphics 42-21

      2. Configuring the Lifetime and Display Mode 42-22

      3. Configuring the Color of Radio Communication

Lines 42-23

image

Chapter 43. Lighting Effects

    1. Displaying Lighting Effects 43-2

    2. Enabling and Disabling Lighting 43-3

      1. Configuring Ambient and Diffuse Lighting 43-4

      2. Specifying the Emissive Lighting Scale 43-5

    3. Displaying Dynamic Lighting 43-6

      1. Daylight Control of Lights 43-7

    4. Displaying Ocean Planar Reflections 43-8

      1. Configuring Ocean Planar Reflections 43-10

    5. Lens Flare 43-10

    6. Displaying Crepuscular (Sun) Rays 43-12

    7. Configuring the Skybox Cube Map 43-14

    8. Flashlight Mode 43-15

    9. Using High Dynamic Range Lighting 43-16

    10. Disabling Lighting and Clouds 43-18

    11. Displaying Shadows (3D Only) 43-19

      1. Configuring Shadows 43-21

image

Chapter 44. Marine Effects

    1. Displaying Water Droplets and Splash Effects 44-2

      1. Enabling Sea Spray 44-4

      2. Setting the Size of Water Droplets 44-5

      3. Enabling High Quality Rotor Wash 44-5

    2. Displaying Wakes and Spray Effects 44-6

    3. Enabling Buoyancy for Surface Entities 44-7

image

Chapter 45. Using Sensors

    1. Using Sensors 45-2

    2. Enabling Sensors 45-3

    3. Configuring Sensors 45-4

    4. Adding New Sensors 45-5

image

Chapter 46. Intervisibility

    1. Intervisibility (Line-of-Sight) 46-2

    2. Types of Intervisibility 46-3

      1. Point-to-Point Intervisibility 46-3

      2. Intervisibility Fan 46-4

      3. Entity Intervisibility 46-4

    3. Intervisibility Objects can be Transient or Permanent 46-5

      1. Creating a Transient Intervisibility Object 46-6

      2. Creating a Permanent Intervisibility Object 46-7

    4. Editing an Intervisibility Object 46-8

    5. Configuring Intervisibility Lines and Fans 46-9

    6. Pinning an Intervisibility Object to a Simulation Object 46-10

    7. Showing and Hiding Intervisibility Lines 46-10

    8. Displaying Intervisibility Line Information 46-11

    9. Displaying an Intervisibility Line’s Terrain Profile 46-12

    10. Deleting Intervisibility Objects 46-12

image

Chapter 47. Sound Effects

    1. Introduction to Sound Effects 47-2

    2. Enabling Sound Effects 47-2

      1. Setting the Sound Volume 47-3

      2. Specifying the Range in which Sounds are Heard 47-3

    3. Associating Sound Files with Entities and Events 47-4

      1. Mapping a Sound File to an Entity 47-5

      2. Mapping Sound Files to Fire and Detonation Events 47-8

Section IX The Observer and Viewing Scenarios

image

Chapter 48. The Observer and Observer Modes

    1. Switching Between the 2D and 3D Projections 48-2

    2. Observer Modes 48-2

    3. Changing the Observer Mode 48-3

    4. Creating and Editing Observer Modes 48-3

      1. Creating an Observer Mode 48-4

      2. Deleting an Observer Mode 48-5

      3. Editing an Observer Mode 48-5

      4. Renaming an Observer Mode 48-5

    5. Adding an Observer 48-6

      1. Adding an Observer on the Observer Settings Page 48-6

      2. Adding an Observer in the Display Engine

        Configuration Editor 48-7

    6. Removing an Observer 48-9

    7. Introduction to XR Mode 48-10

    8. Model Sets 48-11

      1. Changing the Model Set 48-11

    9. Communicating Information About the Observer 48-11

      1. Making the Observer Visible to Other Applications 48-11

      2. Viewing and Attaching to Other Observers 48-12

    10. Displaying Models for Remote Observers 48-12

image

Chapter 49. Moving the Observer

    1. Moving the Observer 49-3

      1. Using the Compass to View the Observer’s Heading 49-4

      2. Editing the Compass’s Attributes 49-5

    2. Observer Movement Functions and Keyboard Mappings 49-6

      1. 3D Observer Movement Coordinate Systems 49-7

      2. 2D Observer Coordinate System 49-7

      3. The Attached Context and Observer Movement

        (3D Only) 49-8

    3. Moving the Observer from the Keyboard in the 3D View 49-10

      1. Navigation Options 49-12

      2. Orbiting 49-13

      3. Moving the Camera 49-13

    4. Moving the Observer Using the Mouse (3D View) 49-14

      1. Dragging the Terrain 49-14

      2. Changing the Observer’s Orientation with the Mouse 49-15

      3. Dragging the View 49-15

      4. Orbiting the Terrain with the Mouse 49-15

      5. Teleporting the Observer 49-16

    5. Moving the Observer in the 2D View 49-16

      1. Moving the Observer from the Keyboard in the

        2D View 49-17

      2. Moving the Observer Using the Mouse in the

        2D Projection 49-18

    6. Zooming the Observer 49-18

      1. Zooming the Observer in the 3D Projection 49-19

      2. Zooming the Observer in the 2D Projection 49-20

      3. Setting the Scale Factor for Paged LODs 49-20

      4. Setting the Magnification LOD Angle for Paged LODs ... 49-21 49.6.5. Zooming to Extents 49-22

    7. Using the Depth of Field Effect 49-23

      1. Configuring Depth of Field 49-25

    8. Centering the Observer on a Simulation Object 49-26

      1. Centering on an Object from the Object Console

        Summary Panel 49-26

      2. Centering on an Object From an Information Panel 49-26

    9. Simulating Camera Jitter 49-27

    10. Forcing Orientation North 49-27

    11. Enabling and Disabling View Constraints (3D Only) 49-28

    12. Controlling Navigation Speed 49-28

      1. Enabling or Disabling Speed Scaling 49-29

      2. Changing the Observer’s Movement Speed 49-30

    13. Saving and Recalling Views 49-30

      1. Recalling a View 49-31

      2. Deleting Views 49-32

      3. Specifying the Startup View 49-32

      4. Saving Views to a File 49-33

      5. Loading Views 49-33

    14. Controlling the Observer from Other Applications 49-34

      1. Enabling the Processing of View Control Messages 49-34

image

Chapter 50. Attaching the Observer to Objects

    1. Attaching the Observer to a Simulation Object or Prop 50-2

      1. Attaching the Observer to Another Observer 50-4

      2. Attaching to an Articulated Part 50-4

      3. Attaching the Observer in Mimic Track or Tether

        Track Mode 50-4

      4. Attaching the Observer in Mimic Location Track or

        Tether Location Track Mode 50-5

      5. Filtering the Object Attachment List 50-5

      6. Detaching from a Simulation Object 50-5

      7. Hiding the Attached Model (3D Projection Only) 50-6

      8. Attaching to Props 50-6

      9. Improving Performance when Attaching to Ground Objects 50- 6

    2. Attach Modes in the 3D View 50-7

      1. Absolute Mode 50-7

      2. Follow Mode 50-8

      3. Mimic Mode 50-9

      4. Mimic Track Mode 50-10

      5. Mimic Location Track Mode 50-10

      6. Space Follow Mode 50-11

      7. Tether Mode 50-12

      8. Tether Track Mode 50-13

      9. Tether Location Track Mode 50-13

      10. Track Mode 50-14

    3. Attach Modes in the 2D View 50-15

    4. Attaching the Observer at Startup 50-15

image

Chapter 51. Inset Views, Sensor FOVs, and HUDs

    1. Inset Views 51-2

    2. Displaying Cockpit Displays (3D Only) 51-3

    3. Displaying Instrument Panels 51-6

      1. Configuring Entities to Use Instrument Panels 51-7

    4. Displaying Sensor Views (3D Only) 51-8

      1. Displaying a Sensor Field of View Cone 51-9

      2. Controlling the Sensor View 51-10

Section X Terrain

image

Chapter 52. Introduction to Terrain Usage in VR-Forces

    1. Composing Terrains (and Creating MTF Files) 52-2

    2. Supported File Formats 52-2

      1. Terrain Data 52-3

      2. Elevation Data 52-3

      3. Supported Image Formats 52-4

      4. Supported Feature Data Formats in the Front-end 52-4

    3. Feature Layers and Props 52-4

      1. Geometric Representation of Point Feature Data 52-5

      2. Feature Data Types Supported by the Back-end 52-5

    4. Coordinate Systems 52-6

      1. The UTM Coordinate System 52-6

      2. Geocentric Terrain Databases 52-6

    5. Loading Supported Databases 52-7

    6. Using Large Terrain Databases 52-7

      1. Terrain Paging 52-8

      2. Terrain Streaming 52-9

image

Chapter 53. Displaying Terrain Information

    1. Introduction 53-2

    2. Configuring Visible Surfaces (GDB Soil Types) 53-2

    3. Coloring Terrain Based on Elevation 53-4

      1. Configuring Elevation Color Settings 53-5

    4. Displaying Grid Lines 53-7

      1. Configuring Grid Lines 53-8

    5. Displaying Contour Lines 53-9

      1. Configuring Contour Lines 53-10

    6. Displaying Models and Terrain in Wireframe Mode 53-10

    7. Filtering Earth File Layers 53-12

    8. Displaying Feature Data (2D) 53-13

      1. Displaying a List of Vector Features 53-14

      2. Changing the Colors Used for Feature Data 53-15

    9. Displaying Coordinates and Soil Type for a Location 53-16

    10. Viewing the Map Scale 53-17

    11. Using Terrain Draw Areas to View Terrain Polygons 53-18

    12. Terrain Databases Provided with VR-Forces 53-19

image

Chapter 54. Using Terrain Profiles

    1. Terrain Profiles 54-2

      1. Displaying a Line’s Terrain Profile 54-3

      2. Configuring Terrain Profiles 54-3

    2. Analyzing Terrain Using a Terrain Profile Line 54-6

image

Chapter 55. Composing Terrains

    1. Creating a Composed Terrain 55-3

      1. Considerations and Limitations for Building Terrains 55-4

      2. Saving a Terrain 55-4

    2. Adding Elevation Data (Terrain Patches) to a Terrain 55-5

    3. Adding Images to a Terrain 55-7

      1. Changing the Display Order of Raster Maps 55-10

    4. Adding a Feature Layer 55-11

    5. Adding a Dynamic Ocean Layer 55-13

      1. Extracting Water Textures and Adding an Ocean Layer ... 55-15

      2. Adding a Dynamic Ocean Layer Directly 55-16

      3. Setting the Ocean LOD Elevation 55-16

      4. Configuring the Ocean Height Map 55-17

    6. Adding Props to a Terrain 55-19

      1. Extracting Props from a Terrain Patch 55-20

      2. Adding Props from a Feature Layer 55-22

      3. Viewing a List of Props 55-24

      4. Selecting Props 55-24

      5. Setting the Opacity of Props 55-25

      6. Changing a Prop’s Type 55-26

      7. Changing a Prop’s Position or Orientation 55-26

      8. Changing a Prop’s Model Definition 55-26

    7. Specifying Simulation Ocean Settings 55-27

image

Chapter 56. Paged and Streaming Terrains

    1. Connecting to Terrain Servers 56-2

      1. Adding Terrain Server Connections 56-4

      2. Connecting to Terrain Servers through a Proxy 56-5

    2. Loading MetaFlight Terrains 56-5

    3. Preprocessing Paged Terrains 56-6

    4. Manually Paging-In Terrain 56-6

    5. Displaying Information About Paged and Streaming Terrains 56-7

      1. Displaying Information about Feature Paging 56-9

      2. Displaying Additional Terrain Paging Information 56-10

      3. Configuring Terrain Paging for the Back-End 56-12

image

Chapter 57. Editing Earth Files

    1. Earth Files 57-3

    2. A Simple Earth File 57-3

      1. Including External Files into Earth Files 57-5

    3. Supported Drivers 57-6

    4. Loading Multiple DTED Files 57-6

    5. Processing Streamed Data 57-7

    6. Adding Feature Layers to an Earth File 57-8

      1. Configuring Point Features 57-10

      2. Configuring Linear Features 57-11

      3. Configuring Areal Features 57-12

    7. Extruded Buildings 57-13

    8. Using Cut-in Sites for High Resolution Insets 57-14

      1. Using the Boundary Generation Tool 57-15

    9. Loading CDB Databases 57-17

      1. Configuring Elevation Data for CDB 57-17

      2. Configuring Image Data for CDB 57-19

    10. Earth File Options 57-21

    11. Differential Processing of Elements and Attributes 57-21

      1. Differential Processing of model Elements 57-22

    12. Streaming Buoys and Beacons 57-23

      1. Specifying Model Definitions for Streamed Buoys 57-24

      2. Modeling Buoys Using Texture Atlases 57-27

      3. Configuring Streaming Beacons 57-28

      4. Configuring Streamed Navigation Lights 57-29

      5. Configuring Seasonal Buoys and Beacons 57-30

      6. Streaming Daymarks 57-30

      7. Streaming Topmarks 57-31

      8. Generating Signal Sequences 57-31

image

Chapter 58. Generating Navigation Data

    1. Introduction 58-2

    2. Creating Navigation Areas 58-3

      1. Editing a Navigation Area 58-4

      2. Reverting Edits to Navigation Area 58-5

      3. Displaying Navigation Areas 58-5

      4. Removing a Navigation Area 58-5

    3. Generating Navigation Data 58-5

      1. Navigation Data Profiles 58-6

      2. Generating Navigation Data for a Navigation Area 58-6

      3. Using Newly Generated Navigation Data 58-8

    4. Generating Navigation Data for Entities 58-9

    5. Importing Navigation Areas and Navigation Data 58-10

    6. Displaying Navigation Data 58-11

      1. Opening Navigation Lab from an Information

        Dialog Box 58-12

      2. Showing Simulation Object Movement in

Navigation Lab 58-13

image

Chapter 59. Dynamic Terrain

    1. Introduction to Dynamic Terrain 59-2

    2. Manually Changing the Terrain 59-2

      1. Resetting Dynamic Terrain Changes 59-2

    3. Removing Dynamic Terrain Damage 59-3

    4. Creating Dynamic Terrain Areas 59-3

    5. Dynamic Terrain Switch Types 59-3

image

Chapter 60. Processing MetaFlight Files

    1. Building Efficient MetaFlight Terrains for VR-Forces 60-2

    2. Processing MetaFlight Files for Use in VR-Forces 60-3

    3. Splitting Datasets into Individual MetaFlight Files 60-3

    4. Converting Virtual Texture Datasets to Tiled Textures 60-4

      1. The mftTool 60-4

      2. Using the mftTool to Process MetaFlight Files 60-6

      3. Convert Geometry Grid Datasets with Tiled Textures 60-7

    5. Convert Source Data into MEDF Format 60-7

    6. Create an MTF File for the MetaFlight Terrain 60-8

image

Chapter 61. Terrain Performance and Configuration

    1. Configuring File Caching 61-2

      1. Specifying the Location to Cache Terrain Server Data 61-3

      2. Caching earth File Terrain Data 61-3

      3. Caching earth File Terrain Data Offline 61-5

      4. Enabling Texture Compression 61-6

      5. Clearing the File Cache 61-6

    2. Using Shader-based Effect Maps 61-7

      1. Debugging Shaders 61-8

      2. Reloading Shaders 61-9

    3. Displaying DDS Textures Correctly 61-10

      1. Flipping DDS Textures Globally 61-11

    4. Displaying Terrain Intersection Lines 61-12

    5. Converting OpenFlight File Texture Data 61-13

    6. Debugging Earth Files 61-14

image

Chapter 62. Configuring Feature Data

    1. Introduction 62-2

    2. Specifying Different Feature Names for the Front-End and

      Back-end 62-2

    3. Named Queries 62-3

    4. Feature Configuration Attributes 62-4

    5. Attribute Transformations 62-4

      1. Transformations as Aliases 62-4

      2. Transformations as Derived Attributes 62-5

      3. Transformations as New Attributes 62-5

      4. Writing Multiple Transforms to Account for Possible

        Failures 62-5

    6. Source-Specific Configuration 62-5

      1. Loading Source-Specific Configuration Files 62-6

      2. Redefining Queries 62-6

    7. Extracting Feature Data from GDB to Shapefiles 62-7

    8. Converting S-57 Feature Data to Shapefiles 62-7

    9. Configuring Aggregate-Level Movement Restrictions 62-9

    10. Dynamic Features 62-10

image

Chapter 63. Terrain Tutorials

    1. Composing a Terrain through the GUI 63-2

      1. Add Elevation Data (Add a Terrain Patch) 63-3

      2. Add Imagery 63-5

      3. Add a Feature Layer 63-9

      4. Add Props 63-10

    2. Creating a Terrain with an Earth File 63-14

      1. Add a Map Element 63-15

      2. Add Elevation Data to the Earth File 63-15

      3. Add Imagery to the Earth File 63-15

      4. Add Feature Data to the Earth File 63-16

      5. Add Options to the Earth File 63-18

      6. Save the Earth File 63-18

      7. Load the Earth File and Save is as an MTF File 63-19

    3. Extracting Props from a Terrain 63-20

      1. Create a New Terrain and Add a Terrain Patch 63-21

      2. Extract the Props 63-21

      3. Change the Model Definition for a Prop 63-23

Section XI Creating and Editing Simulation Models

image

Chapter 64. The Simulation Object Editor and SMSs

    1. Introduction to the Simulation Object Editor 64-3

    2. Starting the Simulation Object Editor 64-4

    3. Simulation Model Sets 64-5

      1. Including Simulation Model Sets in other Simulation

        Model Sets 64-6

      2. SMS Priority for Included and Multiple SMSs 64-8

      3. Lua Scripts in Included SMSs 64-9

      4. Application Level Files in Included SMSs 64-9

      5. Search Paths for Referenced Files in an SMS 64-10

      6. Promoting a Model to the Loaded SMS 64-11

    4. Visual Model Definitions 64-12

      1. User-Created Visual Definition Files 64-12

    5. Migrating an SMS to a New Release 64-13

      1. Upgrading Old Simulation Model Sets 64-14

    6. Opening a Simulation Model Set 64-16

    7. Creating a New Simulation Model Set 64-17

      1. Creating a Completely New Simulation Model Set 64-18

      2. Specifying the Default Simulation Model Set for

        Scenarios 64-18

    8. Importing .entity Files 64-18

    9. Applying Platform Updates 64-19

    10. Editing the Category List 64-19

      1. Adding a New Category 64-20

      2. Removing a Category 64-20

      3. Renaming a Category 64-21

      4. Undoing Category Changes 64-21

    11. Managing the Forces List 64-22

      1. Adding a Force 64-22

      2. Editing a Force 64-23

      3. Removing a Force 64-24

image

Chapter 65. Editing Simulation Object Models

    1. Editing Generic Object Parameters 65-3

      1. Selecting an Object to Edit 65-3

      2. Editing an Object’s Categories 65-3

      3. Changing an Object’s Object Type Enumeration 65-4

      4. Changing an Object’s Name 65-7

      5. Specifying Whether an Object Can Be Created 65-7

      6. Specifying the Object Creation Palette 65-7

      7. Specifying the Default Overlay 65-8

      8. Specifying the Platform 65-8

      9. Undoing (Reverting) Changes to an Object 65-8

    2. Editing Parameters that are Specific to Simulation Objects 65-9

      1. Editing a Simulation Object’s Used By Countries List 65-9

      2. Editing a Simulation Object’s Bounding Volume (Size) ... 65-10

      3. Displaying a Simulation Object’s Bounding Volume 65-11

      4. Specifying Support Points 65-12

      5. Excluding Entities from Batch Bounding Volume and

        Support Point Updates 65-12

      6. Editing Behavioral Parameters 65-12

      7. Adding Object Geometry to an Entity 65-14

      8. Ground Clamping Cultural Features 65-15

      9. Editing a Lifeform’s Visual Model and Animation 65-16

    3. Editing a Simulation Object’s Visual Model 65-19

      1. Changing the 3D Model or Colorized Model 65-20

      2. Changing the 2D Icon Using a Font 65-21

      3. Changing the 2D Icon Using an Image 65-21

      4. Editing a Spot Report Icon 65-23

      5. Adding a New Visual Model or Image 65-24

      6. Displaying Details about the Visual Model 65-25

      7. Importing Visual Models 65-26

      8. Pruning Visual Models 65-26

      9. Exporting Visual Models 65-27

      10. Reloading Visual Models in the VR-Forces GUI 65-27

    4. Editing a Simulation Object’s Systems 65-28

      1. Adding a System 65-30

      2. Selecting a Damage Model 65-30

      3. Selecting a Movement Model 65-30

      4. Editing a System’s Properties 65-31

      5. Editing a System in the OPD Editor 65-31

      6. Removing a System 65-32

    5. Creating a New Simulation Object 65-32

      1. Creating a New Model from an Existing Model 65-33

    6. Deleting an Object Model 65-34

    7. Configuring Embarkation 65-34

      1. Adding Ingress and Egress Points 65-36

      2. Configuring Slots 65-38

    8. Configuring Wakes 65-41

    9. Creating Randomized Simulation Objects 65-43

    10. Creating a Simulation Object Group 65-45

      1. Setting the Simulation Connection when Creating an

        SOG 65-46

    11. Navigating Among Edited Simulation Objects 65-46

    12. Configuring Scripted Entity Movement 65-47

      1. Configuring Ballistic Missile Movement 65-48

      2. Configuring Animated Movement 65-50

      3. Editing Movement File Configurations 65-51

    13. Editing Tactical Graphics 65-53

      1. Editing a Tactical Graphic’s Menu Icon 65-53

      2. Setting the Default Values for Tactical Graphics

        Properties 65-54

      3. Specifying the Properties that can be Edited in the

        Front-End 65-55

      4. Editing the Visual Model for a Tactical Graphic 65-56

image

Chapter 66. Editing Units for Entity-Level Scenarios

    1. Introduction to Editing Units 66-2

    2. Creating a Unit for Entity-Level Scenarios 66-2

    3. Specifying an Aggregate As Option 66-3

    4. Editing Unit Composition 66-4

      1. Adding Subordinates 66-5

      2. Removing Subordinates 66-5

      3. Replacing Subordinates 66-6

      4. Changing the Order of Subordinates 66-6

      5. Editing a Subordinate Unit 66-7

    5. Editing Formations 66-8

      1. Adding Formations 66-9

      2. Removing Formations 66-10

      3. Renaming Formations 66-10

      4. Specifying the Default Formation 66-10

      5. Expanding and Collapsing the Display of Formations 66-10

      6. Displaying Bounding Boxes 66-11

      7. Copying Formations 66-12

      8. Laying Out a Formation Automatically 66-13

      9. Changing a Formation’s Layout by Hand 66-13

image

Chapter 67. Editing Aggregate-Level Objects

    1. Creating Objects for Aggregate-Level Modeling 67-3

    2. Configuring Simulation Objects for Aggregate-Level Modeling 67-3

      1. Aggregating Units into Higher Echelon Units 67-4

    3. Configuring Ammunition, Weapons, and Equipment 67-5

      1. Defining Ammunition, Weapons, and EquipmentItems 67-8

    4. Assemblies 67-10

      1. Creating Assemblies 67-11

      2. Editing Assemblies 67-12

      3. Adding Assemblies to a Unit 67-13

      4. Removing Assemblies 67-13

    5. Creating Roll Up Rules 67-14

    6. Rolling Up Assemblies 67-15

    7. Adding Activities 67-16

    8. Setting Object Parameters for Aggregate-Level Modeling 67-17

      1. Physical Parameters 67-18

      2. Movement Parameters 67-19

      3. Sensor Parameters 67-21

      4. Attack Parameters 67-22

      5. Defense Parameters 67-23

      6. Electronic Warfare (EW) Parameters 67-23

      7. Personnel and Equipment Parameters 67-24

      8. Supplies Parameters 67-24

    9. Configuring Combat Engineering Objects 67-25

    10. Editing Reader/Writer Key/Value Pairs 67-26

image

Chapter 68. Adding DI-Guy Models to VR-Forces

    1. Adding New DI-Guy Models to VR-Forces 68-2

      1. Copy DI-Guy Files to the Data Directory 68-2

    2. DI-Guy Configuration Files 68-3

      1. Adding a New DI-Guy Animation 68-4

    3. How VR-Forces Maps DI-Guy Models 68-5

    4. Add a New DI-Guy Entity in the Simulation Object Editor 68-5

image

Chapter 69. The Object Parameter Database

    1. The Object Parameter Database 69-2

      1. VR-Forces Classes and Object Parameters 69-3

      2. Object Types 69-4

      3. Parameter Types 69-8

      4. Local and Remote Subcomponents 69-9

    2. Component Descriptors and Parameters 69-13

      1. Common Elements of Component Descriptors 69-13

      2. Configuring the Priority of Components 69-16

    3. Platform Files 69-16

    4. System Definition Files 69-17

      1. Creating a System Definition File 69-17

      2. Configuring System Connections 69-18

    5. Adding Variable Bindings to Platform and System Files 69-21

      1. Adding a Variable Binding 69-22

      2. Making Variables Editable in the Simulation Object

        Editor 69-23

      3. Adding Platform Variable Bindings to the Simulation

        Object Editor 69-23

      4. Adding System Definition File Variables to the

        Simulation Object Editor 69-25

    6. Configuring Units 69-25

    7. Configuring Tactical Graphics 69-26

    8. Pathname Interpretation in Simulation Model Set Files 69-26

    9. Updating Object Parameter Database Files for New Releases 69-27

image

Chapter 70. Using the OPD Editor

    1. The Object Parameter Database Editor 70-2

    2. Starting the OPD Editor 70-2

    3. Loading a Simulation Model Set 70-3

    4. Editing Platforms and Systems 70-4

      1. Creating a New Platform or System from an Existing One . 70-4 70.4.2. Editing Individual Parameters 70-6

            1. Deleting Parameters and Components 70-7

            2. Restoring Parameters 70-7

    5. Adding New Components and Parameters 70-8

      1. Adding New Components 70-8

      2. Changing A Component’s Priority 70-9

      3. Creating A Connection 70-10

      4. Adding New Resource Parameters 70-11

    6. Editing Variables 70-11

    7. Regenerating Platform Files 70-12

    8. Saving Changes to the Object Parameter Database 70-12

image

Chapter 71. Configuring Sensors

    1. Configuring Sensors 71-2

      1. Adding a New Sensor to a Simulation Object 71-2

      2. Editing a Sensor System Definition File 71-4

      3. Specifying a Sensor Signature 71-5

      4. Adding Detection Types or Why Doesn’t My Sensor

        Detect Anything? 71-9

      5. Adding a New Sensor Type 71-9

      6. Illumination and Time of Day 71-12

    2. Detection Tables 71-14

image

Chapter 72. Configuring Weapon Systems and Munition Damage

    1. Introduction to Entity-Level Weapon Systems 72-3

    2. Configuring Direct Fire Ballistic Weapons 72-4

      1. Sensing Targets 72-6

      2. Ammo Select Tables 72-8

      3. Hit Probability Tables 72-9

      4. Damage Probability Tables 72-10

    3. Configuring Missile Systems 72-11

      1. Missile Launcher 72-11

      2. Missile Projectile 72-12

      3. Laser Guided Missile Launcher 72-13

      4. Laser Guided Missile Projectile 72-13

    4. Configuring Indirect Fire Weapons 72-14

    5. Configuring Fixed Weapons 72-16

    6. Configuring Bomb Bay Weapon Systems 72-17

    7. Calculating Damage from Munitions 72-17

    8. Configuring Damage-by-Power 72-18

      1. Configuring the Power of a Detonation 72-19

      2. The Damage File for Damage-By-Power 72-21

      3. Adding a New Power Type 72-23

    9. Configuring Damage-by-Ammo-Type 72-25

      1. Configuring Damage for Damage-by-Ammo-Type 72-26

    10. Configuring Damage for Dynamic Terrain 72-28

      1. Standard Terrain Damage 72-28

      2. High Fidelity Terrain Damage 72-29

    11. Direct Fire Configuration Examples 72-30

      1. Direct Fire Weapon Damage-By-Power Example 72-31

      2. Direct Fire Weapon Damage-by-Ammo-Type Example . 72-36

image

Chapter 73. Configuring Movement Systems

    1. Configuring Formations 73-2

      1. Formation Files 73-3

      2. Creating a User-Defined Formation 73-4

    2. Configuring Obstruction Avoidance 73-4

      1. Configuring Object Types 73-5

      2. Configuring Vector Feature Types 73-5

    3. Configuring Embarkation 73-6

image

Chapter 74. Configuring Emitters and Radios

    1. Configuring Emitters 74-2

    2. Configuring Radios 74-4

      1. Publishing Radio Transmitters 74-4

image

Chapter 75. Configuring Joystick and Keyboard Controls

    1. Configuring Joysticks and Keyboard Control 75-2

      1. Creating a Joystick Configuration 75-4

      2. Mapping the Joystick Stick 75-6

      3. Mapping Joystick Buttons and Keyboard Keys 75-7

      4. Configuring “Switch Between” Options 75-10

      5. Using Multiple Joysticks 75-13

      6. Specifying a Favorite Joystick Configuration 75-14

image

Chapter 76. Attaching Components to Remote Entities

76.1. Attaching VR-Forces Components to Remote Entities 76-2

Section XII Configuring the Graphical User Interface

image

Chapter 77. Display Engine and Window Management

    1. The Display Engine 77-2

      1. Window Types 77-2

    2. Managing Display Engine Configurations 77-2

      1. Adding a Window 77-2

      2. Adding a Channel to a Window 77-4

      3. Removing a Window 77-5

      4. Removing a Channel 77-5

      5. Saving a Display Engine Configuration 77-5

      6. Loading a Display Engine Configuration 77-5

    3. Changing a Window’s Attributes 77-6

    4. Changing a Channel’s Attributes 77-7

      1. Setting the Clipping Planes 77-9

      2. Specifying the Projection Resize Policy Attribute 77-11

      3. Changing a Channel’s Frustum (Field of View) 77-14

      4. Changing the Viewport 77-15

      5. Configuring Water Visibility 77-16

    5. Configuring Multichannel Displays 77-17

      1. Changing the Camera’s Position and Orientation Offset .. 77-19 77.6. Stereoscopic Displays 77-20

      1. Configuring Anaglyphic Stereo 77-21

      2. Configuring Polarized Stereo 77-22

Chapter 78. GUI Controls, Layouts, and Behaviors

    1. Dockable Panels and Toolbars 78-2

      1. Docking and Undocking a Panel 78-2

      2. Docking and Undocking a Toolbar 78-3

      3. Displaying and Hiding Panels and Toolbars 78-3

    2. Saving Window Layouts 78-3

      1. Creating a Window Layout 78-4

      2. Choosing the Window Layout 78-5

      3. Setting a Window Layout as the Default Layout 78-5

      4. Reverting a Window Layout 78-6

      5. Updating a Window Layout 78-6

      6. Renaming a Window Layout 78-7

      7. Deleting a Window Layout 78-7

      8. Restoring a Factory Layout 78-7

    3. Using Tear-Off Menus 78-8

    4. Viewing the Window in Full Screen Mode 78-9

    5. Using Context-Sensitive Menus 78-9

    6. Common VR-Forces Buttons 78-9

    7. Adding Text to the Title Bar 78-10

    8. Specifying Display Units 78-11

image

Chapter 79. Configuring Toolbars, Dialog Boxes, and Menus

    1. Introduction 79-2

    2. Configuring Menus and Menu Commands 79-2

    3. Configuring Dialog Box Pages 79-3

    4. Configuring Context-Sensitive Menus 79-5

    5. Configuring Toolbars 79-6

      1. Creating Toolbars 79-6

      2. Specifying an Icon for a Toolbar Item 79-7

    6. Locking Main GUI Elements 79-7

image

Chapter 80. Creating and Editing Key Mappings

    1. Introduction 80-2

    2. The Key Mapping Editor 80-3

      1. Binary Key Mappings 80-4

    3. Editing a Key Map 80-4

      1. Adding a Key Mapping 80-5

      2. Changing a Key Mapping 80-7

      3. Deleting a Key Mapping 80-7

    4. Using Combined Key Mappings 80-8

    5. Filtering the Function List 80-9

    6. Creating a Key Map 80-9

    7. Deleting a Key Map 80-9

Section XIIIConfiguring Visual Models in the Visual Models Editor

    1. Introduction to Object Modeling 80-2

      Chapter 81. Model and Element Definitions

      image

        1. Managing Model and Element Definitions 81-3

        2. Creating and Editing Schemas 81-4

          1. Creating Schemas 81-5

          2. Deleting Schemas 81-6

          3. Copying Schemas 81-6

          4. Adding a Parameter to a Schema 81-7


      81.2.6. Editing a Schema Parameter 81-8

        1. Creating and Editing Model Definitions 81-9

          1. Work Flow Issues for Creating and Editing Model

            Definitions 81-10

          2. Creating a Model Definition 81-12

          3. Deleting a Model Definition 81-13

          4. Copying a Model Definition 81-14

          5. Filtering the List of Model Definitions 81-15

          6. Editing a Model Definition 81-15

          7. Saving Model Definitions 81-18

          8. Importing Model Definitions 81-19

          9. Exporting Model Definitions 81-20

        2. Creating and Editing Element Definitions 81-21

          1. How Entity, Unit, and Tactical Graphics Element

            Definitions are Organized 81-21

          2. Work Flow Issues for Creating and Editing Element

            Definitions 81-23

          3. Creating an Element Definition 81-24

          4. Editing an Element Definition 81-25

          5. Deleting an Element Definition 81-32

          6. Saving Element Definitions 81-32

          7. Importing Element Definitions 81-33

          8. Exporting Element Definitions 81-35

      image

      Chapter 82. Mapping Models and Effects

        1. Introduction to Object Type Mapping 82-2

          1. Work Flow Issues for Creating and Editing Object

            Type Mappings 82-2

          2. Adding an Object Type Mapping 82-4

          3. Editing an Object Type Mapping 82-5

          4. Filtering the Element Definition List 82-7

          5. Deleting an Object Type Mapping 82-7

          6. Saving Simulation Object Type Mappings 82-8

          7. Importing Simulation Object Type Mappings 82-8

          8. Exporting Simulation Object Type Mappings 82-9

          9. Starting without Default Simulation Object Type

            Mappings 82-9

          10. How VR-Forces Maps DI-Guy Models 82-10

      image

      Chapter 83. 2D Icons, Cockpits, Wakes and other Visual Models

        1. Configuring 2D Icons 83-2

          1. Editing Font-Based 2D Icons 83-2

          2. Using Images for 2D Icons 83-4

          3. Adding Images for Simulation Object Icons 83-9

        2. Adding New Cockpit Display Models 83-10

          1. Installing a Cockpit DLL 83-11

          2. Creating a Model Definition for a Cockpit 83-11

        3. Adding Object Models as Props 83-13

          1. Adding a Category to the Props Palette 83-14

        4. Configuring Wakes 83-14

          1. Configuring Tidal Stream Wakes 83-17

        5. Adding Wind-based Controls to Models 83-18

        6. Using Texture Atlases to Skin Models 83-19

          1. Configuring Texture Mapping in the Model Definition ... 83-19 83.6.2. Metafiles for Texture Mapping 83-20

        7. Flipping DDS Textures for a Model 83-21

        8. Configuring SpeedTree Trees 83-22

          1. Randomizing the Size of SpeedTrees 83-24

        9. Best Practices for Creating Models for VR-Forces 83-26

        10. Compressing Model Files 83-27

      image

      Chapter 84. Configuring Emitter Volumes

        1. Configuring Emitter Volumes 84-2

          1. Configuring Emitter Volume Color 84-2

          2. Controlling Emitter Volume Radius 84-3

          3. Configuring Emitter Volume Segments 84-4

      image

      Chapter 85. The WRM Specification (DIS Notes)

        1. Introduction 85-2

        2. The OpenFlight File Format 85-3

          1. Node Name and Comment Fields 85-3

          2. External References and Instancing 85-3

        3. Modeling for DIS Interoperability 85-3

          1. The DIS Attribute Lexicon (DAL) 85-4

          2. DAL Keywords 85-4

          3. Model Coordinate Systems 85-5

        4. Articulated Parts 85-7

        5. Entity Appearances 85-8

        6. Animation 85-11

        7. DIS Keyword Values 85-12

      Section XIVAppendixes

      Appendix A. MTL Syntax

      image

      A.1. Introduction .................................................................................... A-2 A.2. MÄK Technologies Lisp (MTL) Files .............................................. A-3

      A.2.1. Using Environment Variables in an MTL File ...................... A-3 A.2.2. Specifying Lists of Lists ......................................................... A-4 A.2.3. Using Conditional Statements .............................................. A-4


      Appendix B. The vrfSim.mtl Configuration File

      image

      B.1. The vrfSim.mtl Configuration File ................................................... B-2

      Appendix C. Object Parameters

      image

      C.1. The Structure of a Simulation Object Parameter ............................. C-2 C.2. The Parameter Type Hierarchy ....................................................... C-3 C.2.1. Vrf Base Object Parameters .................................................. C-3 C.2.2. Vrf Object Parameters .......................................................... C-7 C.2.3. Moving Object Parameters ................................................... C-8

      C.2.4. Parameter Types for Entity Platforms ................................... C-8 C.3. Simulation Object Parameters ......................................................... C-8 C.4. Object Type Enumerations .............................................................. C-9 C.4.1. Object Super-type ................................................................. C-9 C.4.2. AggregateKind ...................................................................... C-9 C.4.3. ObjectKind ......................................................................... C-10 C.4.4. Unit Category ..................................................................... C-10 C.4.5. Unit Specific ....................................................................... C-11 C.4.6. Point Object Category ........................................................ C-12 C.4.7. Linear Object Category ....................................................... C-12 C.4.8. Areal Object Category ........................................................ C-12 C.4.9. Interaction .......................................................................... C-12

      Appendix D. Systems and System Usage

      image

      D.1. VR-Forces Systems ......................................................................... D-2

      MÄK Products Glossary Index

      VR-Forces Quick Reference Card


      image

      Preface


      This manual is written for persons who will install VR-Forces® or use the VR-Forces application. The manual assumes that you are familiar with your operating system and that you know how to work in your computer’s graphical window environment.

      Please see release documentation for information about changes and updates to VR- Forces since this manual went to press.


      How This Manual is Organized

      The chapters are organized as follows:

      • Section I, “Introduction, Installation, and Startup”

        • Chapter 1, Introduction to VR-Forces, briefly describes VR-Forces and its features.

        • Chapter 2, Installing VR-Forces, explains how to install VR-Forces, set up license management, and localize the GUI.

        • Chapter 3, VR-Forces Application Concepts, provides the conceptual background for the simulation process. It will help put some of the discussion in this manual into context.

        • Chapter 4, Starting VR-Forces describes how to start VR-Forces, load terrain databases, and configure HLA time management.

        • Chapter 5, Command-line Options, describes the command-line options for vrfGui (the front-end) and vrfSim (the back-end or simulation engine).

        • Chapter 6, Optimizing Performance describes how to monitor VR-Forces’s performance in the Frame Rate Monitor and how to configure VR-Forces to improve performance.

      • Section II, “Scenarios”

        • Chapter 7, Creating and Running Scenarios, explains how to create and run scenarios, how to create batch scenarios, and how to checkpoint scenarios.



How to Contact Us

For VR-Forces technical support, information about upgrades, and information about other MAK products, you can contact us in the following ways:


Telephone

Call or fax us at: Voice: Fax:


617-876-8085 (extension 3 for support)

617-876-9208


E-mail

Sales and upgrade information: Technical support:


info@mak.com support@mak.com


Internet

MAK web site home page: www.mak.com

License key requests: www.mak.com/support/licenses/ get-licenses

Product version and platform information: www.mak.com/support/product-versions For the free, unlicensed MAK RTI: www.mak.com/support/resources/bonus-

material

MAK Community Forum: www.mak.com/connect/forum


Post

Send postal correspondence to: VT MAK

150 Cambridge Park Drive, 3rd Floor Cambridge, MA, USA 02140


When requesting support, please tell us the product you are using, the version, and the platform on which you are running.


image

Document Conventions

Preface — Document Conventions

This manual uses the following typographic conventions: Monospaced Indicates commands or values you enter. Monospaced Bold Indicates a key on the keyboard.

Monospaced Italic Indicates command variables that you replace with appropriate values.

Blue text A hypertext link to another location in this manual or another manual in the documentation set.

{ } Indicates required arguments.

[ ] Indicates optional arguments.

| Separates options in a command where only one option may be chosen at a time.

( | ) In command syntax, indicates equivalent alternatives for a command-line option, for example, (-h | --help).

/ Indicates a directory. Since MAK products run on both Linux and Windows PC platforms, we use the / (slash) for generic discus- sions of pathnames. If you are running on a PC, substitute a \ (backslash) when you type pathnames.

Italic Indicates a file name, pathname, or a class name.

sans Serif Indicates a parameter or argument.

Indicates a one-step procedure.

Menu Option Indicates a menu choice. For example, an instruction to select the Save option from the File menu appears as:

Choose File Save.

image

Click the icon to run a tutorial video in the default browser.


!

!

i Indicates supplemental or clarifying information.

Indicates additional information that you must observe to ensure the success of a procedure or other task.


image

Indicates that a section is valid only for entity-level scenarios.


image

Indicates that a section is valid only for aggregate-level scenarios.


Directory names are preceded with dot and slash characters that show their position with respect to the VR-Forces home directory. For example, the directory vrforces4.5/doc appears in the text as ./doc.


Mouse Button Naming Conventions

An instruction to click the mouse button, refers to clicking the primary mouse button, usually the left button for right-handed mice and the right button for left-handed mice. The context-sensitive menu, also called a popup menu or right-click menu, refers to the menu displayed when you click the secondary mouse button, usually the right button on right-handed mice and the left button on left-handed mice.


Third Party Licenses

MAK software products may use code from third parties. This section contains the license documentation required by these third parties.


Boost License

VR-Link, and all MAK software that uses VR-Link uses some code that is distributed under the Boost License. All header files that contain Boost code are properly attributed. The Boost web site is: www.boost.org.

Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the “Software”) to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:

The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEAL- INGS IN THE SOFTWARE.


image

libXML and libICONV

Preface — Third Party Licenses


Lua

VR-Link and all MAK software that uses VR-Link, links in libXML and libICONV. On some platforms the compiled libraries and header files are distributed with MAK Products. MAK has made no modifications to these libraries. For more information about these libraries please see the following web sites:

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


Third-Party Licenses for VR-Vantage Applications

VR-Vantage applications use a variety of third-party libraries. Developers who want to use these libraries may be required to purchase developer’s licenses. Please see section

    1. in VR-Forces Front-End Developers Guide for details.


      image

      1. Introduction, Installation, and Startup


        VR-Forces is a computer generated forces (CGF) application and toolkit. VR-Forces is implemented using separate front-end (graphical user interface) and back-end (simula- tion engine) applications that allow tremendous flexibility for managing your simula- tion needs.



        VR-Forces Users Guide


        Section I - Introduction, Installation, and Startup


        I-1

        Introduction, Installation, and Startup

        image


        Section I - Introduction, Installation, and Startup

        I-2 VT MAK


        image 1. Introduction to VR- Forces


        This chapter provides a high-level description of VR-Forces features.

        Overview 1-3

        Entity-Level and Aggregate-Level Simulation 1-5

        Realistic Display of Vehicles and Terrain (3D View) 1-7

        Create Complex Scenarios 1-7

        Simulation Object Types Supported 1-8

        Mission Planning 1-10

        Simulation Object Tasks 1-10

        Scripted Tasks and Set Data Requests 1-11

        Tactical Graphics 1-11

        Terrain Agility and Composability 1-12

        Crowd Behaviors and Pattern of Life 1-12

        Flexible, Intuitive Graphical User Interface 1-13

        Overlays 1-13

        Behaviors 1-13

        Observer Attach Modes 1-14

        Special Effects and Simulation Object Information Visualization 1-14

        Dynamic Ocean 1-14

        Lighting Effects 1-15

        Accurate Vehicle Positioning 1-15

        Batch Mode Operation 1-15

        Remote Control 1-16

        The VR-Forces Toolkit 1-16

        Plug-in Architecture 1-16

        DI-Guy 1-17

        Support for External Communications Servers 1-17

        image

        Introduction to VR-Forces

        Helpful Utilities 1-18

        Third-Party Software and Content 1-19

        SilverLining 1-19

        Triton Ocean SDK 1-20

        GL Studio 1-20

        SpeedTree 1-21

        3D Models, Terrain, and Graphical Content 1-21

        OpenSceneGraph 1-22

        osgEarth 1-22

        Distributed Simulation Standards Supported 1-22

          1. Overview

            VR-Forces is a computer generated forces (CGF) application and toolkit. VR-Forces is implemented using separate front-end (graphical user interface) and back-end (simula- tion engine) applications that allow tremendous flexibility for managing your simula- tion needs. (For information about how this works, please see “The VR-Forces Program,” on page 3-2.)

            VR-Forces provides 3D and 2D views of your simulated world, integrated into one graphical user interface (GUI). The 2D view provides you with insights into a simu- lated battle by overlaying simulation objects and information onto 2D views of tactical, strategic, and visual databases. The 2D view answers typical questions about the place- ment of forces and how the terrain might affect the engagement more easily than do three-dimensional displays. It is ideally suited for viewing simulations over large areas of open terrain.

            The 3D view provides three-dimensional, perspective views of the terrain and entity models. It is ideal for scenarios that require situational awareness, simulation debug- ging, or after action review. It is particularly useful for placing entities with precise loca- tion and orientation and for working in terrains in which entities can be at multiple altitudes at a given X, Y coordinate, such as urban terrains.

            The 3D view includes exaggerated reality (XR) features. Model scaling and additional model sets help to provide a common operational picture of the simulated world.

            VR-Forces is compatible with the Distributed Interactive Simulation (DIS) and High Level Architecture (HLA) simulation standards. It supports multiple database formats and terrain servers. VR-Forces is interoperable with other MAK products, such as VR- Vantage Stealth and MAK Data Logger.

            The VR-Forces front-end is built with the VR-Vantage Toolkit. The VR-Vantage Toolkit is based on OpenSceneGraph1, so you can leverage value-added plug-ins built by the OSG community and MÄK partners.


            image


            1. “OpenSceneGraph is an Open Source, cross-platform graphics toolkit for the development of high- performance graphics applications such as flight simulators, games, virtual reality and scientific visu- alization. It is based on the concept of a SceneGraph, providing an object-oriented framework on top of OpenGL.” (http://www.openscenegraph.org/projects/osg/wiki/About/Introduction)


              Table 1-1 lists VR-Forces visual features supported in the 3D and 2D views for entity- level scenarios.


              Table 1-1: VR-Forces features by projection (Sheet 1 of 2)

              Feature

              3D

              2D

              Terrain agility and composability

              X

              X

              Attach modes

              X

              X

              Observer movement modes

              Observer frame

              X

              X

              Level observer frame

              X

              Laptop

              X

              X

              2D level observer frame

              X

              Model sets

              3D models

              X

              X (top view)

              3D colorized models

              X

              X (top view)

              2D icons

              X

              X

              Other Features

              Audio

              X

              X

              Cockpit displays

              X

              Communications lines

              X

              X

              Detonation and muzzle flashes

              X

              DI-Guy characters

              X

              Display units configuration

              X

              X

              Dynamic ocean

              X

              Dynamic terrain

              X

              X

              Emitter volumes

              X

              X

              Entity labels

              Text panels

              Configurable symbol decorations

              Environment effects

              X

              Extruded tactical graphics

              X

              Fire and detonation lines

              X

              X

              Forward+ lighting

              X

              High dynamic range lighting

              X

              Intervisibility

              X

              X

              Paged terrain

              X

              X


              Table 1-1: VR-Forces features by projection (Sheet 2 of 2)


              Feature

              3D

              2D

              Range rings

              X

              X

              Remote draw API

              X

              X (2D graphics only)

              Sea spray effects

              X

              Sensors

              X

              X (Stealth only)

              Sensor contact lines

              X

              X

              Shader-based effects maps

              X

              Shadows

              X

              SpeedTree trees

              X

              Streaming buoys and beacons

              X

              X

              Streaming terrain

              X

              X

              Tactical graphics

              X

              X

              Tactical smoke

              X

              Task visualization

              X

              X

              Terrain profiles

              X

              X

              Tracers

              X

              Track histories

              X

              X

              Trailing effects

              X

              View controls

              X

              X

              Wireframe view

              X

              X

              Zoom

              X

              X


                  1. Entity-Level and Aggregate-Level Simulation

                    VR-Forces supports two approaches to simulation – entity-level simulation and aggre- gate-level simulation. In entity-level simulations, VR-Forces models individual entities, such as ships, tanks, automobiles, airplanes, and people. Interaction, and for military simulations, warfare, takes place between individual entities. You can aggregate entities into hierarchical units, but for the most part they are still modeled as individuals.


                    Aggregate-level simulations do not model individual entity interactions and combat. They are concerned with the high level movement and interaction of large numbers of personnel and equipment. Aggregate-level combat is modeled based on the relative strengths and weaknesses of hierarchical units in personnel, equipment, and location, not on the engagement of the individual entities that they represent. Aggregate-level simulations are used for modeling the operational tempo of large area/theater level missions overseen by command staff level officers. This is useful for training staff offi- cers and stimulating Command and Control systems (for example, C2, C4I, C4ISR, and Mission Command systems). (Aggregate-level simulations include some entity models to facilitate certain types of munition attacks. However, they use the same modeling approach as units. They do not behave like the comparable entities in entity- level simulations.)


                    image

                    i

                    i

                    Most of the information in VR-Forces documentation applies to both types of modeling. The procedures for creating scenarios, adding simulation objects and tactical graphics, assigning tasks and writing plans, and displaying scenario information are almost identical in both types of scenarios.

                    Therefore, if you want to know how to create a scenario that uses aggregate- level modeling, for example, just follow the procedures in Chapter 7, Creating and Running Scenarios. Or, if you want to learn about assigning tasks in entity-level scenarios, just read Chapter 26, Assigning Tasks.

                    image

                    If a section only applies to entity-level scenarios, it has an entity icon ( ) in the margin. If a section only applies to aggregate-level scenarios, it has a unit icon image) in the margin.


                    image


                    For conceptual information about the differences between entity-level modeling and aggregate-level modeling, please see the following sections:

                  2. Realistic Display of Vehicles and Terrain (3D View)

                    VR-Forces provides a realistic display using terrain and moving-model geometry in the OpenFlight format. It includes many 3D vehicle models, some of which display move- ment of articulated parts, such as turrets and rotors. These models can change to show a damaged or destroyed state. You can provide your own models and map them to object types. For details about terrain, please see Chapter 55, Composing Terrains. For details about models, please see Chapter 82, Mapping Models and Effects.


                    image

                    i Aggregate-level scenarios do not use 3D vehicle models.

                    image

                  3. Create Complex Scenarios

                    VR-Forces lets you create complex scenarios to meet your simulation requirements. You can:

                    • Create and delete simulation objects.

                    • Create, delete, and edit tactical graphics.

                    • Assign a sequence of tasks and set data requests to a simulation object as a plan.

                    • Assign tasks and set data requests independently of plans.

                    • Create global plans that run independently of any simulation object.

                    • Observe the behavior of simulation objects in response to their environment.

                    • Create, save, and load scenarios that consist of:

                      • Terrain database information.

                      • An order of battle.

                      • Tactical graphics.

                      • A plan for each simulation object in the order of battle.

                    • Manage hostility relationships.

                    • Manage spot reports.

                    • Determine line-of-sight between simulation objects.

                    • Aggregate and disaggregate, and expand and collapse units.

                    • Create overlays and add tactical graphics and simulation objects to them.

                    • Schedule scenario events to inject non-simulated input, such as text, video, and graphics to scenario participants.

                    • Apply weather conditions to a particular area of the terrain.


                  4. Simulation Object Types Supported

                    Using VR-Forces, you can interactively add simulation objects to a simulation and you can aggregate them into higher echelon units. Simulation objects provided for entity- level scenarios include:

                  5. Mission Planning

                    You can create plans for simulation objects that contain tasks, set data requests, condi- tional statements and global commands. You can save plans and edit them.

                    Conditional statements specify that tasks will be executed only if a specific condition is true or false. Some of the conditions tested are:

                    • Is a simulation object in a specific area?

                    • Is a simulation object destroyed?

                    • Is a simulation object to the left or right of a phase line?

                      In addition to conditional statements that are checked only once (If statements), VR- Forces supports Triggers, While statements, and Wait Until statements.


                      Global Plans

                      Global plans exist independently of any simulation object. They allow you to assign tasks and set data requests to simulation objects and execute other commands. In essence, they allow you to script the sorts of ad hoc actions that a VR-Forces user could take through the GUI. This provides a great amount of flexibility to automatically modify the order of battle and tactical graphics in response to events.

                      For more information, please see Chapter 36, Writing Plans.


                  6. Simulation Object Tasks

                    You can assign tasks to simulation objects as part of a plan or independently. The tasks supported in entity-level scenarios include:

                  7. Scripted Tasks and Set Data Requests

                    You can create new tasks and set data requests by writing scripts using the Lua scripting language. Input dialog boxes are created automatically. The scripted action can be added to the Task or Set menu. This feature requires some programming skills, but you do not need a developers license or a C++ development environment. For more infor- mation please see Chapter 32, Creating Scripted Tasks and Sets.

                    Reactive tasks are a special kind of scripted task. They monitor the simulation and get executed only if some special condition is met. You can manage assignment of reactive tasks in the GUI. For more information, please see “Reactive Tasks,” on page 26-12.

                    Background processes are another special type of scripted task. They run continuously and manage ongoing simulation object activities. There is no user interface for managing them. For more information, please see “Background Processes,” on

                    page 33-30.

                    You can organize scripts into groups called Behavior Sets. By assigning Behavior Sets to forces you can control whether or not scripts are available to simulation objects in those forces. For more information, please see “Using Behavior Sets to Manage Scripts,” on page 26-19.


                  8. Tactical Graphics

                    Using VR-Forces, you can interactively create and name tactical graphics, such as:

                  9. Terrain Agility and Composability

                    VR-Forces allows you to build your terrain at runtime using a variety of database and vector formats. It can load OpenFlight DTED, CTDB, CDB, MetaFlight, and GDB (MAK terrain format) databases. It can load feature data from shapefiles, S-57 files, and GDB files. You can also superimpose geospatial images such as GeoTiffs or other raster image files on the terrain.

                    You can load local terrain data and you can stream data from networked servers using the osgEarth earth file format.


                    image

                    i VR-Forces only supports geocentric terrains in osgEarth earth files.

                    image

                    You can save these composed terrains in the MTF file format. For details, please see Chapter 55, Composing Terrains. For a list of supported file formats, please see “Supported File Formats,” on page 52-2.

                    VR-Forces supports the following coordinate systems:

                    • UTM

                    • Geocentric

                    • MGRS

                    • Latitude, longitude

                    • Database.

                    You can overlay raster images, such as CADRG, BMP, and geotiff files on terrain data- bases.


                    Dynamic Terrain

                    Terrain state can be changed using switch nodes in the terrain models. Terrain changes can be caused by munition damage, user initiated changes, and using entity tasks.


                  10. Crowd Behaviors and Pattern of Life

                    You can quickly create civilian crowds that have inherent behaviors of wandering and fleeing munition detonations. You can assign tasks to crowds, such as gathering around a person or point. For details, please see Chapter 21, Crowds and Multiple Simulation Objects.

                    You can use the pattern of life feature to generate civilian and vehicular traffic using various spawn patterns to simulate typical background traffic for scenarios. For details, please see Chapter 20, Generating Traffic (Pattern of Life).


                  11. Flexible, Intuitive Graphical User Interface

                    VR-Forces’s graphical user interface (GUI) allows you to manipulate VR-Forces from menus, dockable control panels, and the keyboard.

                    The VR-Forces display includes the following features:

                    • Manipulate the simulation map by zooming and panning.

                    • Select and track simulation objects.

                    • Turn display features on and off.

                    • Display a hierarchical, echelon view of simulation objects and an embarkation view.

                    • Display entity labels that include several types of information.

                    • Display line-of-sight (intervisibility) for simulation objects.

                      You can hide and display the control panels, keep them docked to the screen, or undock them to make more space available for the display window. The GUI controls can be hidden for full-screen demonstrations.

                      The GUI follows standard conventions for modern windowing systems. For additional details, please see Appendix 78, GUI Controls, Layouts, and Behaviors. For descriptions of individual windows and dialog boxes, please see online help.


                  12. Overlays

                    Overlays mimic clear plastic sheets that a planner might use to draw graphics on top of a terrain map. All objects are automatically assigned to overlays. You can add overlays and move objects between overlays. You can hide the display of objects on an overlay. For details, please see “Overlays,” on page 38-1.


                  13. Behaviors

                    Simulation objects understand how to interact with their environment. For example, they can:

                    • Respond appropriately to other simulation objects and tactical graphics, for example, avoiding simulation objects, waiting for orders, and so on.

                    • Respond to detected targets, for example, deciding which of multiple targets to acquire, which weapon to fire, and what ammunition to use.

                    • Follow a route.


                  14. Observer Attach Modes

                    The observer represents your eyepoint in the simulated terrain. VR-Forces offers attach modes that let you:

                    • Manually control the observer’s position and orientation. (The observer represents the user’s view, or eyepoint, in the simulated world.)

                    • Follow a simulation object, maintaining a consistent positional offset, with a matching heading.

                    • Mimic a vehicle’s position and orientation. You can place the observer inside the vehicle for a driver’s-eye view, or fly outside of it, moving in tandem with the vehicle.

                    • Tether the observer to a simulation object, maintaining a consistent positional offset without changing the observer’s heading.

                    • Automatically track a vehicle’s movement from a fixed viewpoint, as if watching from a control tower.

                      For more information, please see Chapter 49, Moving the Observer.


                  15. Special Effects and Simulation Object Information Visualization

                    VR-Forces includes features that help you understand the interaction between simula- tion objects that add a realistic tone to interactions. These features include:

                    • Fire and detonation lines.

                    • Track histories.

                    • Range rings.

                    • Radio communications lines.

                    • Trailing effects such as footprints, tire tracks, and wakes.


                  16. Dynamic Ocean

                    VR-Forces provides dynamic ocean visualization in the Stealth and Out-the-Window observer modes. The ocean shows waves, swells, and spray effects. Surface entities have realistic wakes and buoyancy behavior. Changes to wind speed and direction affect wave action.


                  17. Lighting Effects

                    VR-Forces supports a variety of lighting effects, including:

                  18. Accurate Vehicle Positioning

                    VR-Forces can smooth the trajectories of moving vehicles to compensate for discontin- uous positional data. The ground clamping feature can ensure that all ground entities are placed correctly on the terrain surface. For details, please see “Trajectory Smoothing,” on page 6-16 and “Using Ground Clamping,” on page 19-20.


                  19. Batch Mode Operation

                    Batch mode allows you to run a scenario multiple times or run several different scenarios, without direct action through the graphical user interface. This is useful for running unattended testing or to test the results of a scenario under differing condi- tions. You can record the results of batch mode simulations using the MAK Data Logger, for later review. For more information, please see “Running VR-Forces in Batch Mode,” on page 7-36.

                    Introduction to VR-Forces — The VR-Forces Toolkit

                    image

                  20. Remote Control

              You can control the VR-Forces observer remotely through view control messages, which can be generated by MAK applications such as MAK Data Logger, and by programs that use the VR-Vantage Control Toolkit. For details, please see “Controlling the Observer from Other Applications,” on page 49-34.

              You can also send view control messages from plans. For details, please see “Sending View Control Messages,” on page 36-35.


                1. The VR-Forces Toolkit

                  The VR-Forces toolkit lets you develop CGF applications. You can enhance the capa- bilities of the VR-Forces simulation engine and GUI, or integrate the simulation engine into your own user interface. The toolkit has several APIs. The Simulation API gives you control over:

                  • Behaviors

                  • Components

                  • Object types

                  • Parameters

                  • Messages

                  • Resources

                  • Tactical graphics

                  • Plans

                  • Tasks.

              The Remote Control API allows you to control a VR-Forces simulation engine from a remote application, such as a graphical user interface (GUI). The Terrain API lets you manipulate terrain databases.

              The VR-Forces front-end is built with the VR-Vantage Toolkit. The toolkit is included with VR-Forces, allowing you to modify or extend the front-end. For details about the VR-Forces Toolkit, please see VR-Forces Developers Guide.


                  1. Plug-in Architecture

                    You can modify the VR-Forces front-end and back-end by rebuilding the applications or by writing plug-ins. In fact, much of the basic functionality of the front-end is implemented using plug-ins rather than as part of the main executable. Plug-ins are dynamically linked libraries that VR-Forces can load at startup. The rationale for choosing which method to use is described in API documentation. You can manage the use of plug-ins in the front-end. For details, please see “Managing Plug-ins,” on

                    page 4-31.


                    image

                      1. DI-Guy

                        Introduction to VR-Forces — Support for External Communications Servers

                        VR-Forces uses DI-Guy software and content for human character animation.

                        VR-Forces comes with DI-Guy functionality built-in and with a large set of DI-Guy characters, appearances, and animations. A VR-Forces customer does not need a DI- Guy license of any kind to use DI-Guy animated characters in a VR-Forces-based appli- cation (including custom applications built using the VR-Forces Toolkit).

                        However, you need a DI-Guy Developer’s license if you want to:

                      2. Support for External Communications Servers

                        You can configure VR-Forces to use an external communications effects server to control the transmission of radio messages between VR-Forces simulation objects. The communications effects server determines which simulation objects are able to commu- nicate with each other, and how long it takes a message to be transmitted from the orig- inator of the message to the receiver of the message.

                        Any communications effects server that meets the defined interface can be used. For information about the interface, please contact support@mak.com. For more informa- tion, please see Chapter 13, Using a Communications Effects Server.

                        Introduction to VR-Forces — Helpful Utilities

                        image

                      3. Helpful Utilities

                        VR-Forces includes the following utilities for configuring and troubleshooting VR- Forces:


                1. Third-Party Software and Content

                  The VR-Forces front-end includes software and content licensed from third parties, including:


              image

              !

              !

              The run-time and developers’ rights for VR-Forces customers vary from vendor to vendor. Please read this section carefully to understand which rights are included with VR-Forces licenses, and which rights require additional third-party licenses.


              image


                  1. SilverLining

                    VR-Forces uses SilverLining software and content to compute lighting and to render the sky, clouds, sun, and moon. SilverLining is developed by Sundog Software (http://www.sundog-soft.com).

                    Most VR-Forces customers do not need to buy a SilverLining license of any kind. In general, a VR-Forces customer has the right to use the SilverLining technology that is built into VR-Forces in any VR-Forces-based application (including custom applica- tions built using the Toolkit). However, there are two exceptions:

                    • If you want to extend or change the way that MAK has integrated SilverLining into VR-Forces by writing directly to the SilverLining API, then you need a SilverLining Developer’s License.

                    • If you are building a commercial video game or other “mass-market” (consumer- level) commercial product on top of the VR-Forces Toolkit, and the resulting product includes the SilverLining functionality, then you need a SilverLining Developer’s License.

                      SilverLining libraries, textures and other graphics resources are distributed in the VR- Forces package solely so that VR-Forces can use them. Use of SilverLining software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.

                      Introduction to VR-Forces — Third-Party Software and Content

                      image

                  2. Triton Ocean SDK

                    VR-Forces uses the Triton Ocean SDK to render 3D oceans and ship wakes. Triton Ocean is developed by Sundog Software (http://www.sundog-soft.com).

                    Most VR-Forces customers do not need to buy a Triton Ocean license of any kind. In general, a VR-Forces customer has the right to use the Triton Ocean technology that is built into VR-Forces in any VR-Forces-based application (including custom applica- tions built using the Toolkit). However, there are two exceptions:

                    • If you want to extend or change the way that MAK has integrated Triton Ocean into VR-Forces by writing directly to the Triton Ocean API, then you need a SilverLining Developer’s License.

                    • If you are building a commercial video game or other “mass-market” (consumer- level) commercial product on top of the VR-Forces Toolkit, and the resulting product includes the Triton Ocean functionality, then you need a Triton Ocean Developer’s License.

                      Triton Ocean libraries, textures and other graphics resources are distributed in the VR- Forces package solely so that VR-Forces can use them. Use of Triton Ocean software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.


                  3. GL Studio

                    VR-Forces uses GL Studio software and content to render interactive cockpit instru- mentation displays. GL Studio is developed by DiSTI (http://www.disti.com).

                    VR-Forces is delivered with several generic cockpit displays. You can use the built-in cockpit displays in any VR-Forces-based application (including custom applications built using the Toolkit), without a GL Studio license of any kind.

                    If you want to build custom cockpits using the GL Studio editor or GL Studio API, you need a GL Studio Developer’s license. If you want to execute custom cockpits in VR- Forces-based applications (regardless of whether the custom cockpits are built by you or a third party), you need GL Studio Run-Time licenses.

                    GL Studio libraries and graphics resources are distributed in the VR-Forces package solely so that VR-Forces can use them. Use of GL Studio software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.


                  4. SpeedTree

                    VR-Forces uses SpeedTree software and content for animated real-time 3D foliage and vegetation. SpeedTree is developed by Interactive Data Visualization (IDV) (http://www.speedtree.com).

                    A VR-Forces customer does not need a SpeedTree license of any kind to use the SpeedTree functionality that is built into the VR-Forces applications that MAK delivers. You may build and run plug-ins to our out-of-the-box applications without a SpeedTree license, as long as your plug-ins do not need to directly access the SpeedTree API.

                    However, you need a SpeedTree Developer’s license if you want to:

                    • Write a plug-in that uses the SpeedTree API directly to extend or modify the way that SpeedTree is integrated into VR-Forces.

                    • Use the VR-Forces Toolkit to develop new applications, and you want your appli- cations to include SpeedTree functionality.

                      SpeedTree libraries, models, textures, and other graphics resources are distributed in the VR-Forces package solely so that VR-Forces can use them. Use of SpeedTree software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.


                  5. 3D Models, Terrain, and Graphical Content

                    VR-Forces includes a rich set of 3D models for vehicles, weapons, cultural features and urban clutter (signs, barriers, lampposts, and so on). It also includes several sample terrain databases to help you get started with VR-Forces, and to help demonstrate VR- Forces. Much of this content is derived from 3D data that we have licensed from third parties:

                  6. OpenSceneGraph

                    VR-Forces uses OpenSceneGraph for its underlying scene graph representation, rendering, file loading, and many other capabilities. OpenSceneGraph is an open source, cross-platform graphics toolkit for the development of high-performance graphics applications. The OpenSceneGraph source repository is maintained by Robert Osfield at http://www.openscenegraph.org/projects/osg. It is distributed under the OpenSceneGraph Public License (OSGPL), which is based on the GNU Lesser General Public License (LGPL).

                    MAK will provide modified source code for OSG upon request, as per the OSGPL license. Please contact support@mak.com to obtain the download links for our modi- fied source.


                  7. osgEarth

              VR-Forces uses osgEarth to import streaming terrain elevation and imagery data. The data can be streamed from external servers and sources or from a directory on the computer running VR-Forces. osgEarth is an open source plug-in to OpenSceneGraph, maintained by Pelican Mapping at http://osgEarth.org. osgEarth is distributed under the GNU Lesser General Public License (LGPL).

              MAK will provide modified source code for osgEarth upon request, as per the OSGPL license. Please contact support@mak.com to obtain the download links for our modi- fied source.


              1.7. Distributed Simulation Standards Supported

              VR-Forces supports the HLA 1.3 specification, the current draft of the IEEE 1516 C++ API maintained by the SISO Dynamic Link Compatible RTI API Product Develop- ment Group, and HLA Evolved (IEEE 1516-2010). It also supports the Distributed Interactive Simulation (DIS) protocol, versions 4, 5, 6, and 7.

              VR-Forces has built-in support for the HLA RPR-FOM and can support other FOMs through the FOM Mapping feature. For information about FOM mapping, please see “Specifying a FOM Mapper,” on page 5-18. Please see VR-Forces Release Notes for a list of the versions of DIS supported.

              VR-Forces supports time management for HLA exercises.


              image

            2. Installing VR-Forces


        This chapter explains how to install VR-Forces on your computer. It also explains how to install other software required for use with VR-Forces.

        Installing VR-Forces 2-2

        Installing VR-Forces on Windows 2-2

        Installing VR-Forces on a Linux System 2-3

        Uninstalling VR-Forces 2-3

        The VR-Forces Directory Structure 2-4

        Installing and Setting Up the MAK License Manager 2-5

        Specifying the License Server 2-6

        Installing an RTI 2-8

        Installing the MAK RTI 2-9

        Localizing the Graphical User Interface 2-10

        Translating Other Interface Files 2-13

        Translating VR-Forces Scripts and Console Messages 2-14

        Applying the Language Files 2-15

        Merging Translation Files 2-15

        Installing VR-Forces

        image

          1. Installing VR-Forces

            A full VR-Forces installation includes three components: the application, the License Manager software, and for HLA operation, an RTI (or Runtime Infrastructure.)

            Before you install VR-Forces, please read the Release Notes to see if there are any special instructions for installation.

            VR-Forces has two installation files, an application installer and a data package (.MAK- targz). You must run the application installer and then install the data package. The application installer can automatically install the data package if you configure it to do so.

            To install the VR-Forces toolkit, you must enter an installation code. Be sure you have received your code from your MAK salesperson before you start the installation process. If you do not have an installation code, you can install the runtime files. When you receive your installation code you can install the toolkit.


            1. Installing VR-Forces on Windows

              Note the following:

              • You must have administrator privileges to install MAK products on Windows Vista.

              • When you install large applications on Windows Vista or later, there may be a delay of up to several minutes from the time you try to run the setup program to the time that an installation dialog box is displayed. This is due to how Windows scans setup programs before it executes them. If you experience this problem, turning off User Access Control can reduce or eliminate this delay.

                Windows versions of VR-Forces are provided as executable installer files on DVD, or as downloaded files. The installers are named to indicate the compiler used to build that version of VR-Forces.

                To install VR-Forces, run the application installer. Follow the instructions in the installation wizard. You can specify that the application installer automatically find and install the data package (it must be in the same directory as the application installer), or you can specify that the MAK Data Installer open and let you select the data package to install.

                Installing VR-Forces — Installing VR-Forces

                image

            2. Installing VR-Forces on a Linux System

              Linux versions of VR-Forces are provided as compressed tar files on DVD, or as down- loaded files.


              image

              i

              i

              If you install VR-Forces in one directory and user data in another directory, VR-Forces will not start.


              image


              To install VR-Forces on Linux:

              1. Create the directory in which you want to install VR-Forces.

              2. Copy the tar file to the install directory.

              3. Uncompress and untar the application file:

                tar -vxzf application.tar.gz

                where application is the product release identification.

              4. The data package has the extension MAK-targz. Uncompress and untar the data package and copy it into the installation directory, or uncompress it and redirect the output, as follows:

              tar -xzf makData<version>.MAK-targz -C /path-to-vrforc- es4.5

              If you are installing from a DVD, the data package is too large to fit on a single DVD and has been broken up into smaller files. You must put these files back together before you can install the data. Follow the instructions in VR-Forces Data Package Installer Readme.txt, which is included on the DVD.


            3. Uninstalling VR-Forces

              When you uninstall VR-Forces, the uninstaller does not uninstall the data package. You must delete the files manually.

              Installing VR-Forces — The VR-Forces Directory Structure

              image

          2. The VR-Forces Directory Structure

            The VR-Forces installation process creates a directory structure like the one shown in Figure 2-1. On PCs, the default installation directory is C:\MAK\vrforces4.5.)


            vrforces4.5

            image

            appData appsrc backup

            bin64 compatibility data

            doc examples factory include lib64 plugins64 translations userData

            Figure 2-1. VR-Forces directory structure

            Table 2-1 describes the contents of the directories installed by VR-Forces.

            image

            Table 2-1: Contents of VR-Forces directories (Sheet 1 of 2)


            Directory Directory contents

            Directory Directory contents

            ./appData Schema, model definitions, settings, configuration files, and other data.

            ./appsrc Source files and project files for API developers.

            ./backup Backup configuration files.

            ./bin64 or ./bin Product executables and DLLs.

            ./compatibility Header files for compatibility with releases before VR-Forces 4.3.

            ./data The ./data directory has several subdirectories that contain:

            • Bitmaps and icons.

            • Simulation model sets.

            • Terrain database source files.

            • Visual model data.

            ./doc VR-Forces documentation.

            ./examples Sample code for toolkit users.

            ./factory Backups of the application data and settings provided by MAK.

            ./include Header files for use by API developers.

            ./lib64 or /lib Library files.

            image


            image

            Table 2-1: Contents of VR-Forces directories (Sheet 2 of 2)


            Directory Directory contents

            Directory Directory contents

            ./plugins64 or

            ./plugins

            Plug-in DLLs.

            ./translations Files and an executable for localizing the GUI.

            ./userData Scenarios, terrain files, and other files that get created by users as they use VR-Forces.

            image


          3. Installing and Setting Up the MAK License Manager

        Before you can use a MAK product, you must obtain a valid license file, install the MAK License Manager, and configure the license server and client machines. The License Manager uses a client-server architecture, so you do not need to install the License Manager on every computer on which you install MAK products. You only need to install it on the computer that you will use as the license server.


        image

        i

        i

        If you have already installed the License Manager for another MAK product, you do not have to install it again. You just need to make sure you have licenses for your newly installed products.


        image


        The License Manager installer is included on MAK installation media. It is separate from the product installers. You can download the installers from our web site at http://www.mak.com/license-support.html or you can download directly from:

        • Windows:

          ftp://ftp.mak.com/out/MAKLicenseManager-win64-setup.exe

        • Linux:

        ftp://ftp.mak.com/out/MAKLicenseManager-linux64-setup.tar.gz

        Complete installation and configuration instructions are included with the License Manager installer. Instructions are also available at the license support page.

        Some customers use dongle licenses instead of running a license server. Instructions for using dongles are in the License Manager documentation.

        Installing VR-Forces — Installing and Setting Up the MAK License Manager

        image

            1. Specifying the License Server

              The first time you run a MAK application on a particular computer, the License Setup dialog box opens (Figure 2-2). It prompts you to enter the hostname of the license server and optionally, a port number.


              image

              Figure 2-2. License Setup dialog box

              If you do not know the hostname of the license server, click Configure Later. When you have the hostname, you can start the application again and complete the dialog box.

              You will not be able to run any MAK applications until you set up license management.

              If you know the hostname, type it in the Hostname box. Then click OK. The applica- tion will start.

              Under limited circumstances, MAK issues node-locked licenses. If you have a node locked license, select the Use Node Locked License option and enter the path to the license file.


              image

              i

              i

              • If you are running MAK products on the license server machine, it is also a client, so you must specify the license server on that machine too.

              • If you change the license server, the saved configuration will no longer be valid and the License Setup dialog box will open the next time you start a MAK application.

              • You can clear the saved license configuration by deleting the cache file. On Windows, it is C:\Users\user_name\AppData\Roaming\MAK\licenses<n>.txt. (The AppData directory is hidden by default.) On Linux, it is

        .mak/license<n>.txt. (There may be more than one cache file, for example, licenses1.txt and licenses2.txt.)


        image


        The MAKLMGRD_LICENSE_FILE Environment Variable

        As an alternative to using the License Setup procedure described in the previous section, you can configure the license server in an environment variable. The MAKLMGRD_LICENSE_FILE environment variable identifies the server machine. If you set this environment variable, it overrides the settings stored by the License Setup procedure.

        The syntax for the environment variable is: @Server_name. For example, if the server machine is oak, set the environment variable to @oak.

        The following sections explain how to set environment variables on the different plat- forms that MAK products run on.


        Windows

        To add the MAKLMGRD_LICENSE_FILE in Windows:

        1. Open the Control Panel.

        2. Click System and Security.

        3. Click System.

        4. In the sidebar menu, click the Advanced System Settings. The System Properties dialog box opens.

        5. Click Environment Variables. The Environment Variables dialog box opens.

        6. Click New. The New System Variable dialog box opens.

        7. In the Variable Name field, enter MAKLMGRD_LICENSE_FILE.

        8. In the Variable Value field, enter @server_name, where server_name is the name of the license server.

        9. Click OK to back out of each dialog box and set the variable.

        Installing VR-Forces — Installing an RTI

        image


        image

        i

        i

        Different versions of Windows have slightly different wording of the various Control Panel options.


        image


        Linux

        On Linux, you set environment variables in your .cshrc (or equivalent startup file). Set the variable similarly to the following example:

        setenv MAKLMGRD_LICENSE_FILE @oak

        If you are using the sh or bash shells, you set environment variables in your .profile file (or .bashrc). Set the variable similarly to the following example:

        MAKLMGRD_LICENSE_FILE=@oak export MAKLMGRD_LICENSE_FILE

        Do not put spaces around the equal (=) sign.

        You are ready to run the license server and use your new licenses or MAK products.


          1. Installing an RTI

            An RTI is a software library (and perhaps supporting executables) that implements an HLA Interface Specification. In HLA, applications exchange FOM data through RTI calls, which means that all HLA applications need to use an RTI.



            image

            i

            i

            Because of differences in the low-level network mechanisms used by different RTI implementations (which include, but are not limited to packet layout), applications that want to interoperate in the same federation execution must use the same RTI implementation.


            image

            Because RTIs are usually provided as dynamic libraries that implement a fixed API, a federation can often switch from one RTI implementation to another between runs (without even recompiling the applications), but during each run, all participants must agree on which RTI to use, much as they must also agree on which FOM to use.

            For the most recent information about the RTI versions supported by MAK products, please see the release notes for your MAK application.


            image

            1. Installing the MAK RTI

              Installing VR-Forces — Installing an RTI

              To install the MAK RTI, follow the instructions in Chapter 2 of MÄK RTI Users Guide.


              Configuring Your System to Use the MAK RTI

              The RTI dynamic libraries must be located somewhere on your dynamic library search path. The path is specified in the PATH environment variable.The path is indicated by an environment variable as follows:

          2. Localizing the Graphical User Interface

            You can localize your MAK product’s graphical user interface so that it uses languages other than English. Your product includes a file called ./translations/product_untrans- lated.ts, for example logger_untranslated.ts or vrforces_untranslated.ts. The file contains entries for all of the application-specific menu and dialog box text. The Qt Linguist tool, which is included with VR-Forces, lets you map the English text provided by MAK to your chosen language.


            image

            i

            i

            The untranslated.ts file does not include all of the text that may be displayed in the GUI or in console and error messages.

            Some strings, such as those on the Create menu, are in configuration files. Others are in settings files. You can translate these strings by identifying the appropriate configuration file and translating the strings.

            VR-Forces has a utility that can scan system scripts and SMS files and create translation files for user-visible text. For details, please see “Translating VR- Forces Scripts and Console Messages,” on page 2-14.


            image


            To edit a resource file:

            1. Start the Qt Linguist utility. It is ./translations/linguist.exe

            2. In the Qt Linguist window, choose File Open. Select the file ./transla- tions/product_untranslated.ts. The Settings for filename dialog box opens (Figure 2-3).



              image

              Figure 2-3. Linguist settings dialog box

            3. Select values for the source language, target language, and target region or country.

            4. Click OK. The translation file is opened and a list of classes is displayed on the left side of the window (Figure 2-4).



              image

              Source text

              Class

              list


              Translation area


              Figure 2-4. Linguist window

            5. To translate text, you select each class in turn and translate the text associated with that class. You do not have to understand anything about what the classes mean, you just have to translate the text. In Figure 2-4, QMenu is selected. The Strings window lists text that can be translated. Text that has not been translated has a question mark in the checkmark column.

            6. In the Source Text list, select the word you want to translate. The text is displayed under Source Text in the translation area (the window below the source text list.) Figure 2-5 shows the text Open selected.


              image


              Figure 2-5. Text selected for translation

            7. Place the cursor in the text box below Language Translation, where Language is the target language that you selected when you opened the translation file.

            8. Type the translation text.

            9. When you are done and you are certain of the translation, select the Done and image Next button on the toolbar. A green check mark replaces the question mark

              (Figure 2-6). If you move to a different text string without clicking Done and Next, a yellow question mark is displayed for the string you translated. When you trans- late all elements for a class, a green check mark replaces the question mark next to the class name.



              image

              Figure 2-6. Completed translation for Open

            10. Repeat this process for each element of source text for each class.

            11. Choose File Release. The file is saved in the format filename.qm.

            12. Rename the file to a name that indicates the language to which you have translated the file, using the two-character abbreviation typically used with your language. For example, a Spanish translation would be renamed product_es.qm.

            13. Save your translated .ts file.


            1. Translating Other Interface Files

              The vrforces_untranslated.ts file contains all the text used in the VR-Forces interface. However, there may be other text and messages that are not specific to VR-Forces that are generated by the software that implements the VR-Forces GUI. To translate this text, you need to translate the file qt_untranslated.ts. Follow the same procedure as you did for vrforces_untranslated.ts.


            2. Translating VR-Forces Scripts and Console Messages

              The vrforces_untranslated.ts file includes text for dialog boxes and interface elements created using the Qt Toolkit. However, there are many messages generated by code and the dialog boxes for scripts are generated programmatically, rather than through Qt ui files. Therefore they are not included in vrforces_untranslated.ts. VR-Forces has a utility that can scan all system scripts (those in a simulation model set) as well as some of the common SMS files, and create a TS file for each script and SMS. You can then translate the text in the individual TS files. This script also creates a TS file for DI-Guy files.

              For this process to work, you must code messages in your scripts in a certain way. For details, please see “Coding Messages for Translation,” on page 33-21. VR-Forces also has a way to code console messages so that they can be extracted and translated. For details, please see 17.8.1, Coding Object Console Messages for Translation, in VR- Forces Developers Guide.


              Generating TS Files for Scripts and Simulation Model Sets

              If you code your scripts to support translation, you create TS files by running the trans- lationFileCreate utility. By default this application scans ./data/simulationModelSets and its subdirectories for all system scripts and some generic files, and ./appData/settings for DI-Guy files.

              The utility creates an untranslated.ts file for each lua script. This file is saved in the directory that contains the script. It also creates a TS file for each simulation model set, which is saved in the SMS directory, and a diguy_untranslated.ts file, which is saved in

              ./translations.

              When you translate a script file, the translated file must remain with the back-end(s) that are hosting the scripts. The rest of the translated files must exist on the user machine. The .qm file for DI-Guy and VR-Forces must live in the translations directory and the .qm file for the simulation model sets with the .sms files.

              The syntax for translationFileCreate is as follows:

              translationFileCreate.exe [--directory filename] ... [--smsfile string] ... [--nodiguy] [--nosms]

              [--noscripts] [--] [-v] [-h]

              image

              Table 2-2: translationFileCreate arguments


              Argument Description

              Argument Description

              --directory

              directory_name

              Directory to scan for files of any of the supported types (lua, sysdef, xml, mtl) as per creation rules (scripts, systems, supporting). Accepted multiple times.

              (-h | --help) Displays usage information and exits.

              --nodiguy Do not parse the DI-Guy configuration files.

              --noscripts Do not parse Lua files for translation.

              image


              image

              Table 2-2: translationFileCreate arguments


              Argument Description

              Argument Description

              --nosms Do not parse the simulation model set directories for their supporting translatable items.

              --smsfile

              SMS_filename

              Specific SMS file to use when translating simulation model set directories. Accepted multiple times. If not specified, processes all SMS files.

              (-v | --version) Displays version information and exits.

              (-- | --ignore_rest) Ignores the rest of the labeled arguments following this

              flag.

              image


              Generating TS Files for Object Console Messages

              If the messages in your source code are coded for extraction to TS files, you can generate an untranslated.ts file for them. To generate TS files, run:

              lupdate source_directory -ts my_new_translations.ts

              The resulting TS file is saved to the location pointed to by the path given to -ts.


            3. Applying the Language Files

              To put the language file into effect, use one of the following methods:

              • Set your computer’s environment to the proper language (LANG environment variable).

              • Set the locale to the proper language.

              • Start VR-Forces with the -G locale command line option, where locale is the two-letter country code for the local language.


            4. Merging Translation Files

              If you localize a version of VR-Forces and upgrade to a newer version, you can merge your localized .ts file with the .ts file from the new version. Then you only have to trans- late new or changed text in the new version. You merge translation files with the trans- lationMerge utility, which is in the ./bin64 directory. The syntax is as follows:

              translationMerge [-o] [-m] previous.ts current.ts new.ts

              where:

              • previous.ts is the name of the previously localized translation file.

              • current.ts is the name of the translation file provided with the current release of VR-Forces.

              • new.ts is the name to give to the merged file.

              • -o specifies that the merged file removes obsolete messages.

              • -m merges modules that have equal text strings.


        image

        3. VR-Forces Application Concepts


        This chapter describes at a conceptual level the components of a VR-Forces simulation and how they work together.

        The VR-Forces Program 3-2

        Front-end and Back-end Concepts 3-2

        How Front-ends and Back-ends Work Together 3-3

        How VR-Forces Back-ends are Identified 3-4

        VR-Forces Sessions 3-4

        Coordinating Multiple Front-ends 3-6

        Working with Multiple Back-ends 3-7

        Objects 3-8

        The Object Parameter Database 3-8

        Local Objects and Remote Objects 3-9

        Representing and Managing Time in VR-Forces 3-10

        Simulation Time 3-10

        Time of Day 3-10

        Exercise Clock Modes 3-11

        Interactions 3-12

        Advanced Terrain Navigation 3-12

        How Navigation Data is Generated 3-12

        Path Finding 3-14

        VR-Forces Application Concepts — The VR-Forces Program

        image

          1. The VR-Forces Program

            Unlike most computer applications, which have one executable file, VR-Forces has two executable files: a front-end, or graphical user interface (GUI) and a back-end, or simu- lation engine. The front-end executable is vrfGui. The back-end executable is vrfSim- protocol, where protocol is DIS, HLA13, HLA1516, or HLA1516e.

            By separating the simulation engine from the visualization program, VR-Forces allows you to run multiple front-ends, back-ends, or both. If you run multiple front-ends, several VR-Forces users can work together to create and manage scenarios. Using session IDs, you can specify which front-ends control which back-ends. The front-ends also display simulation objects received over the network from other simulations partic- ipating in an exercise. (You have a limited ability to interact with these remote objects. For more information, please see “Local Objects and Remote Objects,” on page 3-9, “Writing Plans for Remote Entities,” on page 36-39 and “Attaching VR-Forces Components to Remote Entities,” on page 76-2.)

            If you run multiple simulation engines, the work of simulating simulation objects and tactical graphics can be shared by multiple computers, which should improve perfor- mance. If you save a scenario, VR-Forces records which objects are simulated by each back-end, so that the configuration can be reproduced the next time you run the scenario.


            image

            i

            i

            In this manual, most procedures apply to interaction with the front-end. For the sake of simplicity, unless we are discussing a subject that applies specifically to either the front-end or back-end, we refer to VR-Forces in the sense of the combined interactions of both executables.


            image


          2. Front-end and Back-end Concepts

            Although the separation of front-ends and back-ends, and the ability to run multiple instances of each adds to the power and flexibility of VR-Forces, you need to under- stand how the various executables interact to ensure that your scenarios are created and run smoothly. In this section, we describe:

            • How front-ends and back-ends work together.

            • How back-ends are uniquely identified.

            • Use of sessions.

            • How to coordinate multiple front-ends.

            • How scenarios are loaded and saved when you run multiple back-ends.


            1. How Front-ends and Back-ends Work Together

              The VR-Forces front-end is an interface to the simulation engine. It communicates with the back-end by sending messages over the network. (This relationship exists even if you are not connected to a network.) It displays the state updates and interactions that the back-end generates and sends over the network. Figure 3-1 illustrates loading a scenario and running a simulation.


              image

              Front-end (GUI)


              Load scenario


              network

              Back-end


              Load terrain



              Send load scenario message to back-end.


              Scenario loaded message.

              Update GUI

              Load scenario message.


              Scenario loaded message.


              Load scenario Load terrain Create objects


              Run simulation


              Update GUI

              Run simulation message.


              State updates

              Run simulation message.


              State updates


              Execute plans Simulate objects



              = User action image = VR-Forces action

              Figure 3-1. Front-end and back-end interaction


            2. How VR-Forces Back-ends are Identified

              If you run multiple back-ends, you can specify which back-end you want to use when you create simulation objects and tactical graphics. This feature allows you to spread the simulation load across multiple PCs. However, to do this, each back-end must have a unique ID. VR-Forces back-ends are identified by their site ID and application number. Each back-end must have a unique site:application identifier. You assign the site:application identifier when you start an application. It is up to you to make sure that there are no duplicate identifiers. (For details, please see “Starting VR-Forces,” on page 4-3.)


              image

              i

              i

              The site ID and application number concepts are borrowed from DIS. They apply to VR-Forces when it is running in HLA as well.


              image


            3. VR-Forces Sessions

              VR-Forces uses sessions to help manage the relationships between front-ends and back- ends. Back-ends are always part of a session. Front-ends can join a session or operate independently of one. When a front-end is joined to a session, it can control the back- ends in that session. When a front-end is not joined to a session, it cannot control back- ends. However, it can open a terrain and view exercises running on its port. In this case it is just a viewer.

              Use of sessions helps ensure consistency among front-ends that are controlling a common set of back-ends. The session mechanism ensures that:

              • All front-ends and back-ends in a session run the same scenario and use the same terrain.

              • When a front-end joins a session that is running a scenario, it automatically loads the correct terrain for the scenario.

              • If any front-end in a session tries to create a scenario or load a scenario, and a scenario is already running, the user is warned that this action will destroy the currently running scenario.

              • If any front-end in a session loads a scenario or creates a new scenario, all of the back-ends and other front-ends in that session take the same action.

                Sessions provide the following additional benefits:

              • They allow you to specify which front-ends control which back-ends. This feature could be useful, for example, if you want one set of VR-Forces applications to simulate friendly forces and another set to simulate opposing forces. If all applica- tions were in the same session, participants could send orders to the simulation objects in the opposing force. By using separate sessions, this is not possible.

                In Figure 3-2, the front-end with session ID 1 can control the back-ends with that same session ID. The front-end with session ID 2, controls the back-end with session ID 2.


                front-end

                front-end

                session ID 1

                session ID 2 front-end

                image image

                image

                session ID 1 session ID 1 session ID 2


                Figure 3-2. Using session ID to control back-ends

                • Sessions allow you to load different terrain databases in different VR-Forces execut- ables that are part of the same exercise. This feature may be helpful if you are participating in an exercise that covers a large geographical area, but only need to observe portions of that total terrain. Loading databases that cover a subset of the total exercise zone could improve the performance of your computer or the resolu- tion of the terrain database.

                  In Figure 3-3, the two sessions have loaded databases that cover different (but over- lapping) portions of California, USA. The entire exercise would cover the terrain covered by two databases.



                  image image

                  session ID 1 session ID 2


                  Figure 3-3. Using session IDs to load different terrain databases


                  If two different sessions use terrain databases that overlap, note the following possible sources of confusion:

              • The front-ends in each session will see simulation objects from the other session that are simulated in the common portions of the terrain. However, the front-end for one session will have no ability to control the simulation objects that are simu- lated by the other session.

              • If you save the scenario in one of these sessions, it only saves the simulation objects simulated in the session. It does not save the simulation objects from the other session, even though they may be visible in a front-end.

              • If one of the sessions pauses or rewinds, the front-end in the other session will see the simulation objects in the overlapping region pause or return to their origin.

                For more information, please see “Specifying a Session ID,” on page 4-8 and “Managing a Front-end’s Session Connection,” on page 4-14.


            4. Coordinating Multiple Front-ends

              Figure 3-1 shows how a VR-Forces front-end sends messages to a back-end and displays the simulation messages sent out by the back-end. When you run VR-Forces with multiple front-ends, any of them can send control messages to the back-ends and all of them display the state updates. However, you would not want users at different front- ends to send conflicting or overlapping messages. For example, you would not want two different users to try to load the same scenario. Therefore, when you run multiple front-ends, bear the following points in mind:

              • Only one front-end in each session can load a scenario or create a new one (they can all create the objects in the scenario).

              • Any front-end can save a scenario. However, this could lead to multiple, unsyn- chronized versions of a scenario. It is probably best to reserve saving of scenarios to a specific front-end.

              • Any object that you create in any of the front-ends is visible in the others and can be managed from them.

              • You can close the scenario from any front-end.

                VR-Forces provides some help managing multiple front-ends. For example, if one front-end loads a scenario, VR-Forces automatically asks the other front-ends to load the appropriate terrain. And if you close a scenario in one front-end, VR-Forces auto- matically prompts the other front-ends to close their terrains.


            5. Working with Multiple Back-ends

              As noted previously, you can distribute simulation of simulation objects among multiple back-ends. The available back-ends are listed in the Selected Simulation Engine Toolbar (Figure 3-4). If you are running multiple back-ends, when you create simulation objects, you specify which back-end you want to create them on by selecting a back-end in the toolbar. (For more information, please see “Selecting the Object to Create,” on page 16-4.)


              image

              Figure 3-4. Selected Simulation Engine toolbar

              When you run multiple back-ends, bear the following points in mind:

        VR-Forces Application Concepts — Objects

        image


        Remapping Back-ends

        The previous section lists the issues you should consider when creating, saving, and loading scenarios that use multiple back-ends. If you choose to run a scenario that requires multiple back-ends and some of the back-ends are not available, VR-Forces lets you remap objects from the missing back-ends to the available back-ends. You can remap back-ends automatically or manually.

        If a scenario is missing its object map (.omp) file, you can remap the objects and create a new object map file. By default, in combined mode all the simulation objects are remapped to the combined mode back-end. By default, in separate mode the remap- ping dialog box lists the missing back-end as “UNKNOWN”.

        You might also want to manually remap back-ends to load balance a scenario. For more information, please see “Load Balancing a Scenario,” on page 7-19.


          1. Objects

            All simulation objects and tactical graphics are objects. The procedures for selecting, viewing, and organizing different kinds of objects are fairly similar. However since their purposes and use are quite different, for the most part we discuss simulation objects and tactical graphics separately.


            1. The Object Parameter Database

              VR-Forces creates objects based on parameter specifications in the object parameter database (OPD). In the OPD, object types are identified by an 8-field enumeration based on the SISO Enumeration Document (Reference for Enumeration for Simulation Interoperability). (The DIS enumerations have also been incorporated into the HLA RPR FOM.) In this manual, when we refer to entity or force type enumerations, we are referring to this set of enumerations. For information about the object parameter data- base and how to edit it, please see the chapters in Section XI, Creating and Editing Simulation Models.

              The objects in the OPD are organized into simulation model sets (SMS). An SMS contains all of the objects and supporting configuration files needed to populate a scenario. VR-Forces provides an SMS for entity-level scenarios (EntityLevel.sms), one for aggregate-level scenarios (AggregateLevel.sms), and one used by both types of scenarios (base.sms).


              image

            2. Local Objects and Remote Objects

              VR-Forces Application Concepts — Objects

              From the point of view of a particular VR-Forces back-end, a local object is any object that is simulated in that back-end. In that same back-end, a remote object is an object that is received over the network from an external application, such as another VR- Forces simulation engine, or a non-VR-Forces simulation. A given VR-Forces applica- tion participating in a networked exercise may know about a mixture of local and remote objects.

              There are two categories of remote objects: objects simulated by VR-Forces applica- tions, and objects simulated by applications other than VR-Forces. When VR-Forces learns about a non-VR-Forces remote object, it knows only what is transmitted in the standard DIS or HLA message. By contrast, VR-Forces remote objects share additional state information over the network, including a unique identifier (UUID), a string name, an echelon ID (if the simulation object is organized), and a string label.


              image

              i

              i

              The VR-Forces front-end allows you to manage all the objects in a VR-Forces session regardless of which back-end is simulating them. Therefore, in the interest of simplicity, we refer to simulation objects simulated by a VR-Forces back-end, whether local or remote, simply as simulation objects and we refer to simulation objects simulated by applications other than VR-Forces as remote simulation objects.


              image


              You cannot control remote simulation objects from VR-Forces. However, you can attach VR-Forces components such as sensors and radios to remote simulation objects and you can write plans that use these components. For more information, please see “Writing Plans for Remote Entities,” on page 36-39 and “Attaching VR-Forces Components to Remote Entities,” on page 76-2.

              VR-Forces Application Concepts — Representing and Managing Time in VR-Forces

              image

          2. Representing and Managing Time in VR-Forces

            VR-Forces maintains an exercise clock. The clock keeps track of elapsed simulation time, date, and time of day. In HLA federations, it may be affected by federation time. These concepts also have a relationship to wall-clock, or real time.


            1. Simulation Time

              Elapsed simulation time is the amount of time that has passed since the simulation started, and is expressed in days, hours, minutes, and seconds in the format 00:00:00:00.

              Application developers can manipulate simulation time. Unless a local developer tells you otherwise, simulation time starts at 00:00:00:00.


              Simulation starts


              End of 24 hrs.


              End of 36 hrs.


              End of 48 hrs.

              image

              00:00:00:00 01:00:00:00 01:12:00:00 02:00:00:00

              Elapsed simulation time



            2. Time of Day

              Figure 3-5. Simulation time

              VR-Forces represents the day/night cycle with the Time of Day value. By default, it starts at 10:00 A.M in the time zone of the first simulation object created in a scenario, but can be set when you create a scenario. Time of day affects the simulation. For example, visual sensors are less able to detect objects at night than they are in the day.

              Normally, time of day advances with simulation time, however you can change the time of day after the scenario is created, and even while the scenario is running. You can reset the time of day at any time through the environment settings, or through a plan with the Set Time of Day command. For details, please see “Introduction to Environment Conditions,” on page 11-2.

              The display of time of day in the interface is 00:00 in hours and minutes. Time of day does not track number of days; when the time of day reaches midnight, is starts over at 00:00.

              VR-Forces Application Concepts — Representing and Managing Time in VR-Forces

              image

            3. Exercise Clock Modes

              The exercise clock supports the following modes:

          3. Interactions

            VR-Forces displays interactions, such as detonations, that it receives in interaction messages or PDUs. You cannot select or otherwise manipulate them. You can only view them.


          4. Advanced Terrain Navigation

            VR-Forces supports advanced terrain navigation for entities based on the Autodesk® Gameware Navigation artificial intelligence software. Using Gameware Navigation Lab, you can create topological models of the virtual 3D environment that allow VR-Forces to compute, in real time, an optimized path for entity movement. As entities follow the path, they automatically avoid obstacles and other entities. The topological models are called navigation data.


            image

            i

            i

            Gameware Navigation Lab is included with VR-Forces. You can use it to view the navigation data included with VR-Forces terrain databases. If you want to generate navigation data, you must purchase an additional license.


            image


            1. How Navigation Data is Generated

              Navigation data is generated from the front-end. Before you can use newly generated navigation data, you must close your scenario and reopen it. (This is so it can be loaded by the back-end.) If the terrain is modified, the navigation data must be generated again.

              VR-Forces analyzes the terrain and creates a navigation mesh (NavMesh) of the terrain. The NavMesh defines areas in which an entity can move, given its dimensions. A life- form can move in spaces that a ground vehicle cannot move in. Figure 3-6 shows a NavMesh for a terrain that has several areas in which entities cannot move.


              image

              Obstacle


              Obstacle Obstacle


              Figure 3-6. NavMesh

              image

              Based on the NavMesh, VR-Forces generates a graph of locations in the terrain that the entity type can move to. Each location can be accessed from at least one other location. Figure 3-7 shows a hypothetical graph of the paths that an entity can follow in the NavMesh shown in Figure 3-6.


              Obstacle

              Obstacle


              Obstacle

              Obstacle

              Obstacle

              Obstacle


              Figure 3-7. Graph

              For details about generating navigation data, please see Chapter 58, Generating Naviga- tion Data.


            2. Path Finding

        Path finding is the process by which an entity plans a path, follows the path, and avoids obstacles along the path.


        Planning a Path

        image

        Every time an entity decides to move (either through an autonomous decision or a task assignment), it computes its path. Path computation, or path planning consists of running an A* algorithm, with a given heuristic, on the navigation data.


        Start

        Start


        Obstacle

        Obstacle


        Obstacle

        Obstacle

        Obstacle

        Obstacle


        Figure 3-8. Planning a path

        A path finding heuristic is a cost estimate for the shortest path to reach a target. This cost can be measured according to various criteria, such as distance, time, and danger. The path finding heuristic is critical for the performance of the A* algorithm used by VR-Forces.

        The standard path finding heuristic is the Euclidian Heuristic. In this heuristic, the cost of moving from one vertex to another vertex is the Euclidian length of the connecting edge. VR-Forces also uses a Road Constrained Heuristic, in which a ground vehicle computing its path is forced to move only on roads.


        Path Following

        Once a path is determined for an entity, it can start moving to its final goal. As illus- trated in Figure 3-8, a path is a set of vertices and edges. However, entities do not neces- sarily follow the exact path. VR-Forces smooths the entity’s movement.

        The first intermediary destination (or subgoal) of the entity is the nearest vertex. Before moving towards this point, the entity checks to see if it can move directly to the next vertex in its path. This test is performed against the AI mesh. If the next vertex is reach- able, it becomes the new subgoal. The entity continues testing successive vertices until it finds a vertex that it cannot reach directly. The final trajectory is a smooth line that connects the various subgoals.

        Figures 3-9 and 3-10 illustrate this process. Using the prospective path defined in Figure 3-8, the entity computes its actual path. In Figure 3-9, view 1, it tests the first three vertices (dashed lines) and finds that it can reach all of them directly. In Figure

        3-9, view 2, it tests the fourth vertex and finds that it can reach it. It then tests the fifth vertex and finds it cannot reach it directly. Therefore, the fourth vertex becomes the subgoal for this portion of the path. Figure 3-10 shows the final calculated path (dashed line). Notice how the path to the fourth vertex is much smoother than a path that strictly follows the vertices and edges would be, because the entity determined that it could move directly to that vertex.


        Start

        Start

        Start

        Start


        Obstacle

        Obstacle

        Obstacle

        Obstacle


        Obstacle

        Obstacle

        Obstacle

        Obstacle

        Obstacle

        Obstacle

        Obstacle

        Obstacle


        image

        image

        1 2


        Figure 3-9. Checking next vertex



        Start

        Start



        Obstacle

        Obstacle


        Obstacle

        Obstacle

        Obstacle

        Obstacle


        image

        Figure 3-10. Final calculated path


        Dynamic Avoidance

        While following its path, an entity may encounter other entities. VR-Forces models include collision avoidance. However in complex scenarios, the scenario developer may have to spend a considerable amount of time creating routes and coordinating entities to minimize collisions among entities and obstacles.

        image

        Advanced navigation uses a dynamic avoidance algorithm to make entities behave real- istically when they are about to collide. Entities detect potential collisions in advance and adjust their trajectories smoothly using the navigation data.


        Obstacle

        Obstacle


        Obstacle

        Obstacle

        Obstacle

        Obstacle


        Figure 3-11. Collision avoidance

        In Figure 3-11, two entities traveling in opposite directions avoid each other, then resume their routes. Compare the track of the dashed line to that in Figure 3-10.


        image

        4. Starting VR-Forces


        This chapter explains how to start and stop VR-Forces and load terrain databases.

        Starting VR-Forces 4-3

        Starting VR-Forces from the VR-Forces Launcher 4-3

        Starting Independent VR-Forces Executables 4-8

        Specifying a Session ID 4-8

        VR-Forces Startup Tutorial 4-9

        The VR-Forces Window 4-11

        Opening New Windows 4-13

        Printing the VR-Forces Display 4-13

        Managing a Front-end’s Session Connection 4-14

        Joining a Session 4-15

        Resigning from a Session 4-15

        Configuring Session Messages and Join at Startup 4-16

        Using HLA Time Management 4-17

        VR-Forces Simulation Time Versus Federation Time 4-18

        Configuring Time Management for HLA Exercises 4-18

        Opening a Terrain Database 4-19

        Loading a Terrain Database at Startup 4-21

        Closing a Terrain 4-21

        Managing VR-Forces Settings 4-21

        Synchronizing Settings Among VR-Forces Installations 4-23

        Global Settings and Observer-Specific Settings 4-24

        Exiting VR-Forces 4-24

        Configuring Simulation Connections 4-24

        Opening the Simulation Connections Configuration Dialog Box 4-25

        image

        Starting VR-Forces

        Adding a Simulation Connection 4-26

        Editing a Simulation Connection 4-27

        Simulation Connection Parameters 4-28

        Deleting a Simulation Connection 4-30

        Configuring Auto Connect 4-30

        Displaying Connection Information 4-31

        Managing Plug-ins 4-31

        Loading Plug-ins 4-32

        Adding a Plug-in 4-34

        Specifying the DLLs for a Plug-in 4-35

        Adding a Plug-in Configuration 4-36

        Deleting a Plug-in Configuration 4-36

        Deleting a Plug-in 4-37

        Viewing a List of Loaded Plug-ins 4-37

        The VR-Forces Log Files 4-38

          1. Starting VR-Forces

            In “The VR-Forces Program,” on page 3-2, we describe the VR-Forces front-end and back-end applications. You can start front-ends and back-ends separately, which is called separate mode, or you can use the VR-Forces Launcher to start them together, which is called combined mode. The only real difference between the two startup modes is that in combined mode, when you shut down the front-end, the back-end automatically shuts down also.

            By default, all front-ends and back-ends start with session ID 1. Front-ends automati- cally try to join a session. If no back-ends are running when a front-end starts, it does not join a session. However, if at a later time a back-end with the same session ID starts, the front-end automatically joins the session.


            image

            i

            i

            If you run VR-Forces for HLA, be sure that you have installed an RTI and configured your system to use it. For details, please see “Installing an RTI,” on page 2-8.


            image


            For convenience you can create batch files or scripts to start VR-Forces. Please see Chapter 5, Command-line Options for a list of command-line options.


            1. Starting VR-Forces from the VR-Forces Launcher

              You can run VR-Forces using DIS, HLA 1.3, HLA 1516, or HLA Evolved. For the HLA specifications, you can run using one of several different versions of the RPR FOM. With all these different possible startup configurations, particularly for HLA, it can be confusing to keep track of the options for starting VR-Forces. The VR-Forces Launcher simplifies the process of specifying the simulation standard to use when starting VR-Forces.

              The VR-Forces Launcher lets you start in combined mode or separate mode.


              To start VR-Forces using the VR-Forces Launcher:

              1. On the Start menu, choose Programs MAK Technologies VR-Forces 4.5 VR- Forces configuration.

                Where configuration is:

              2. In the Simulation Connections Configuration dialog box, select a connection configuration. (Optionally, create a new configuration. For details about creating and editing simulation connections, please see “Configuring Simulation Connec- tions,” on page 4-24.)

              3. Optionally, edit the connection’s parameters. If you change a parameter, it is saved automatically.

              4. Optionally, specify additional command line arguments for the front-end, back- end, or both. For a list of command line arguments, please see Chapter 5, Command-line Options.


                image

                i

                i

                • If you click the Browse button at the end of the Additional Command Line Arguments entry for the front-end or back-end, VR-Forces displays the command that will be executed when you click Launch. You can copy the command and use it in a batch file, script, or for debugging.

                • If you start the Launcher from the command line and use the F-- or B-- syntax, those commands are not shown as additional command line arguments. However, they will be executed when you click Launch.


                image


              5. Click Launch. The VR-Forces executables start. When the VR-Forces applications finish their startup process, the Scenario Startup dialog box opens (Figure 4-2). It lets you quickly create or load a scenario using common options.



                image

                Figure 4-2. Scenario Startup dialog box


              6. To create a scenario or load a scenario, select one of the options and click OK. The options are as follows:

              7. If you do not want any of the options, click Close. (This closes the Scenario Setup dialog box; it does not close VR-Forces.)


                Enabling and Disabling the Scenario Startup Dialog Box

                If you do not want VR-Forces to display the Scenario Startup dialog box every time it starts up, you can disable it. You can enable the dialog box at a later time.

                To enable or disable the Scenario Startup dialog box:

                1. Choose Settings Application. The Application Settings dialog box opens.

                2. Select the Session Options page (Figure 4-3).


                  image

                  Figure 4-3. Session Options page

                3. Select or clear the Show Scenario Startup Dialog check box.


                image

                i

                i

                You can also disable display of the Scenario Startup dialog box by selecting Do Not Show This Dialog At Startup on the dialog box itself.


                image


            2. Starting Independent VR-Forces Executables

              To start independent VR-Forces executables:

              1. Open a console window.

              2. Change to the ./bin64 directory.

              3. Enter a command for each VR-Forces executable you want to run. You must specify the protocol to use. For vrfSim, the protocol is part of the executable name. For vrfGui, it is a command-line argument. Specify a unique site:application iden- tifier for each executable, for example:

                vrfGui -s 1 -a 3000 {--dis | --hla13 | --hla1516 |

                --hla1516e} options

                vrfSimprotocol -s 1 -a 3001 options

                vrfSimprotocol -s 2 -a 3001 options

                where protocol is DIS, HLA13, HLA1516, or HLA1516e.

                A VR-Forces window opens for each front-end you start and a console window opens for each back-end. For an example of running multiple front and back-ends, please see “VR-Forces Startup Tutorial,” on page 4-9.


            3. Specifying a Session ID

              To assign a session ID, use the -i command line option.

              vrfGui -s 1 -a 3000 -i 25 {--dis | --hla13 | --hla1516 |

              --hla1516e} options] vrfSimprotocol -s 2 -a 3002 -i 25

              where protocol is DIS, HLA13, HLA1516, or HLA1516e.

              The default session ID is 1. You cannot change the session ID during runtime.


            4. VR-Forces Startup Tutorial

              This section is a brief example of how to run multiple front and back-ends on multiple computers. Examples are provided for DIS and HLA. For both protocols, assume the configuration in Figure 4-4. This configuration has two front-ends and three back- ends. Each is on a different computer. Assume that they are all running in the same session.


              image

              image

              Front-ends


              image

              1 2


              Back-ends


              3 4 5


              Figure 4-4. VR-Forces multicomputer configuration


              image

              i

              i

              As an alternative to starting individual front-ends and back-ends from the command line and specifying their protocol information in the command line, you can use vrfLauncher to start the front-ends and back-ends. Be sure to specify unique site and application numbers in vrfLauncher. For details about vrfLauncher command syntax, please see “Command-line Options for vrfLauncher,” on page 5-14.


              image


              DIS Configuration

              In a DIS exercise, you typically specify a port so that the exercise traffic is isolated from other network traffic. Each front-end and back-end must have a unique site:application ID.

              Run VR-Forces on each PC using the following commands:

              • PC 1:

                vrfGui -s 1 -a 3000 --dis -P 1234

              • PC 2:

                vrfGui -s 1 -a 3001 --dis -P 1234


                vrfSimDIS

                -s

                1

                -a

                3002

                -P

                1234

                vrfSimDIS

                -s

                1

                -a

                3003

                -P

                1234

                vrfSimDIS

                -s

                1

                -a

                3004

                -P

                1234

                • PC 3:

                • PC 4:

                • PC 5:


                HLA Configuration

                In an HLA exercise, you could simply specify the site:application ID and use default values to specify the HLA configuration parameters. Specification of the site:applica- tion ID is identical to that in DIS. For this example, we use HLA 1.3 and specify a FOM Mapper other than the default (RPR FOM 1).

                Run VR-Forces on each PC using the following commands:

              • PC 1:

                vrfGui -s 1 -a 3000 --hla -x MAK-RPR-2.0

                --rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed

              • PC 2:

                vrfGui -s 1 -a 3001 --hla -x MAK-RPR-2.0

                --rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed

              • PC 3:

                vrfSimHLA13 -s 1 -a 3002 -x MAK-RPR-2.0

                --rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed

              • PC 4:

                vrfSimHLA13 -s 1 -a 3003 -x MAK-RPR-2.0

                --rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed

              • PC 5:

              vrfSimHLA13 -s 1 -a 3004 -x MAK-RPR-2.0

              --rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed


          2. The VR-Forces Window

            VR-Forces shows all the simulation objects and interactions on a terrain database. The VR-Forces window has the following main components (Figure 4-5):


            image

            Menus Toolbars



            Panels Palettes


            Terrain and object display


            Figure 4-5. VR-Forces window and toolbars (2D)

            You can view the terrain in 2D (Figure 4-5), 3D (Figure 4-6), and exaggerated reality (XR) (Figure 4-7) modes.

            Starting VR-Forces — The VR-Forces Window

            image


            image

            Figure 4-6. VR-Forces window (3D)


            image

            Figure 4-7. VR-Forces window (XR)

            You can undock toolbars and panels and display them anyplace on your desktop. You can hide any toolbar that you do not want to be visible. (For details, please see Chapter 78, GUI Controls, Layouts, and Behaviors.)


            1. Opening New Windows

              In addition to the main VR-Forces window, you can open secondary windows. These windows do not have any of the menus or toolbars of the main window. However, you can navigate the windows using the same keyboard and mouse options as the main window. When a secondary window has focus, the settings on the Observer Settings toolbar apply to that secondary window and changes you make affect the window.

              You can open windows with a 2D view or 3D view. Once a window is open, you can change the view by changing the observer mode.

              Opening a secondary window is not the same thing as running a second instance of the front-end. When you close a front-end, all secondary windows associated with it are also closed.

              To open a new window, choose File New Stealth Window or File New Plan View Window.


              image

              i

              i

              You can also open a new window by opening an inset view. For details, please see “Inset Views,” on page 51-2.


              image


            2. Printing the VR-Forces Display

              You can print the VR-Forces display to any printer configured on your computer. None of the GUI controls or tabs get printed.

              To print the VR-Forces display:

              1. Choose File Print. The Print dialog box opens.

              2. Select a printer.

              3. Click Print.


          3. Managing a Front-end’s Session Connection

            A front-end can be joined to a session or not joined. When a front-end is not joined to a session, it cannot create, load, or manage a scenario. It can only load a terrain and function as a viewer. You can tell a front-end’s session status by the availability of Join Session and Resign Session commands on the File menu.

            By default, when you start a front-end it automatically tries to join a session. If there is no session running, it polls the network until one becomes available and then automat- ically joins it. Once a front-end is joined to a session, you can manually resign from and rejoin it.

            When a front-end joins a session, its behavior depends on the session options set in the Application Settings dialog box, Session Options page. The options are:

            • Ask to join the session.

            • Always join the session with the session database.

            • Always join the session with whatever database is currently loaded.


            image

            !

            !

            If you do not load the terrain specified by the scenario, it is possible that visual and simulation terrains will not be synchronized.


            image


            image

            1. Joining a Session

              Starting VR-Forces — Managing a Front-end’s Session Connection

              When you join a session, all menu commands related to scenario management are enabled. If a scenario is loaded in the session, the terrain is automatically loaded in the joining front-end.

              To join a session:

              1. Choose File Join Session. If VR-Forces is configured to always join a session with the session database, the front-end loads the session database and joins the session. If VR-Forces is not configured to automatically use the session database, the Join Session dialog box opens (Figure 4-8). If a scenario is running, its details are listed.



                image

                Scenario running No scenario running


                Figure 4-8. Join Session dialog box

              2. If a scenario is running, you can specify that you want to load an alternate terrain:

                1. Select the Join Using Alternate Terrain check box.

                2. Click Join. An Open Database dialog box opens.

                3. Select the terrain that you want to load.

                4. Click Open. The terrain is loaded and the front-end joins the session.


                image

                !

                !

                If you join a session using an alternate terrain, the front-end (visual) and back-end (simulation) terrains might not be synchronized.


                image


              3. Click Join. The front-end joins the session.


            2. Resigning from a Session

              When you resign from a session, all menu commands related to scenario management are disabled. If you have a scenario loaded, the terrain is closed.

              To resign from a session, choose File Resign From Session.


            3. Configuring Session Messages and Join at Startup

              You can configure the display of session-related messages and whether or not the front- end tries to join a session or open a terrain database automatically at startup.

              To configure sessions:

              1. Choose Settings Application. The Application Settings dialog box opens.

              2. Select the Session Options page (Figure 4-3).

              3. Select the options that you want to enable, as follows:

              4. Click Close.


        4.4. Using HLA Time Management

        In HLA, use of time management allows the rate at which a federate proceeds to be controlled by another federate. Federates being controlled by other federates are said to be constrained. Federates that control other federates are time regulating. A federate can be both time regulating and constrained. It can also be unconstrained.

        The main reasons why you might want to enable time management for VR-Forces are to run VR-Forces as part of a wider federation that is using time management or to synchronize multiple VR-Forces back-ends. Without time management, multiple back- ends can stay synchronized only if they all are able to maintain the same frame rate.

        However, if they cannot do so, they will no longer have a shared concept of simulation time and will become unsynchronized. By using time management services, multiple back-ends can be configured to run in lock-step with respect to simulation time, ensuring that events will always happen in the same order.


        image

        i VR-Forces supports time management in the back-end only.

        image

        For details about enabling time management, please see “Configuring Time Manage- ment for HLA Exercises,” on page 4-18.

        Starting VR-Forces — Using HLA Time Management

        image

            1. VR-Forces Simulation Time Versus Federation Time

              Time management synchronizes federates to federation time. Federation time is the common model of time for the federation as whole. It is the time used in time stamp ordered messages (TSO), exchanged by time-managed federates. During the lifetime of a federation, federation time always increases. (There is no notion of rewinding back to an earlier time as with VR-Forces simulation time.)

              VR-Forces simulation time is not the same as HLA federation time. It is the elapsed time within a scenario (the time displayed in the Simulation Time toolbar). When you first start a simulation, federation time and simulation time may be similar. However, if you rewind a time-managed simulation, the discrepancy between the two time streams will increase. This should not have any effect on running and rewinding scenarios. As long as all the back-ends start from the same simulation state when you begin a simula- tion, they will be correctly synchronized (against federation time) as the simulation progresses.


            2. Configuring Time Management for HLA Exercises

              To use time management services in an HLA exercise, you must properly configure an RTI and enable time management in the VR-Forces back-end.

              Time management is enabled at the application level, not the scenario level. Scenarios created without use of time management work in time-managed mode. No time management-specific information is saved as part of a scenario.

              If you enable time management in the back-end, then whenever you create or load a scenario that specifies a fixed-frame mode (that is, the frame-mode parameter in the scenario file is set to either fixed-frame best effort or fixed-frame-run-to-complete), the back-end will become a regulating and constrained federate. It will remain in this state until the scenario is closed.

              A time-managed back-end advances simulation time at a rate that is a function of the frame-mode specified in the scenario it is executing. If the frame-mode is fixed-frame, then it tries to advance simulation time at a rate approximating real time. However, if the back-end has a heavy simulation load, or another time-constrained federate is advancing at a relatively slower rate, the back-end may not achieve this rate. If the frame- mode is fixed-frame-run-to-complete, the back-end tries to advance simulation time as fast as possible, independent of wall-clock time.


              RTI Requirements for Time Management

              To use time management in VR-Forces, your RTI must be properly configured to support this service. If you are using the MAK RTI, set the RTI_useRtiExec and RTI_timeMgmt parameters to 1. When you start the federation, you must run the rtiexec.

              If you are using another RTI, please consult its documentation for configuration instructions.

              Starting VR-Forces — Opening a Terrain Database

              image


              Enabling Time Management for the Back-end

              To enable time management in the back-end, use one of the following methods:

              • Set runInTimeManagementMode to 1 in vrfSim.mtl.

              • Start the back-end with the --timeManagement command-line option. For example, to start the back-end in time management mode using HLA 1.3, the sample FED file configured for use with time management, and the federation name MAK-RPR1-TimeManagement-1-1:

                vrfSimHLAprotocol -s 1 -a 3001 --timeManagement

                -F MAK-RPR1-TimeManagement-1-1.fed -x MAK-RPR1-TimeMan- agement-1-1


                image

                i

                i


        image


          1. Opening a Terrain Database

            If you are using multiple front-ends, when you load or create a scenario, the front-end on which you issue the command loads the correct terrain database. The other front- ends prompt you to load the terrain. However, you can choose to load a different terrain. Also, if you want to use the front-end as a viewer, you can manually load a terrain database. (For a brief description of the databases supplied with VR-Forces, please see “Terrain Databases Provided with VR-Forces,” on page 53-19.)

            You can only “open” terrains in MTF format. To open any other terrain format, you must compose a terrain, as described in Chapter 55, Composing Terrains, or use an earth file, as described in Chapter 56, Paged and Streaming Terrains.

            The first time you load a terrain (including the terrains supplied with VR-Forces), VR- Forces caches textures in its fast load format. This is a slow process. However, thereafter the terrain will load quickly. If you want to avoid runtime caching, you can preprocess the terrain with the medfTool before you load it. (For details about the medfTool, please see “Compressing Model Files,” on page 83-27.) If you want to disable runtime caching, you can do so as described in “Configuring File Caching,” on page 61-2.


            image

            !

            !

            It is possible to open a terrain without having a scenario loaded. In such cases you can create tactical graphics and add props, but you cannot create simulation objects. To create and manipulate simulation objects, you must load or create a scenario.


            image

            Starting VR-Forces — Opening a Terrain Database

            image


            To open a terrain database:

            1. In the VR-Forces window, choose File Open Terrain. The Open Terrain dialog box opens.

            2. Select the terrain that you want to open.

            3. Click Open. The database is displayed in the VR-Forces window (Figure 4-9).


              image

              Figure 4-9. VR-Forces window with a database loaded


              image

              i

              i

              • If you load a terrain database while one is currently loaded, VR-Forces closes the current database and then opens the new one.

              • Paged terrains might not be visible when loaded in Plan View mode. To see the terrain, press e to zoom in. This problem potentially exists for all paged terrains whose page-in distance is less than the default observer distance in Plan View mode.

              • Some MetaFlight terrains do not display in the 2D view when first loaded. To see the terrain, change to a 3D view mode, and press the space bar (center view on terrain) to move the eyepoint to the terrain location. After this, the terrain can be viewed in the 2D view.


            image


            1. Loading a Terrain Database at Startup

              You can load a terrain database at startup by specifying it on the command line. If you start VR-Forces while a session is running, it can load the appropriate terrain database automatically. For details, please see “Configuring Session Messages and Join at Startup,” on page 4-16.

              To load a terrain database when you start VR-Forces, use the -T command line option.

              vrfSimprotocol -s 1 -a 3001 -T “../userData/terrains/myDa- tabase.mtf”

              where protocol is DIS, HLA13, HLA1516, or HLA1516e.


            2. Closing a Terrain

              To close a terrain, use one of the following methods:

              • Choose File Close Terrain.

              • Choose File New Terrain.

              • Open a different terrain.


          1. Managing VR-Forces Settings

            VR-Forces has the following types of settings:

        Starting VR-Forces — Managing VR-Forces Settings

        image


        VR-Forces manages settings as follows:

        • As you make changes to settings during a session, it saves the changes, except for model definitions, element definitions, and simulation object type mappings.

        • It remembers the settings in effect when you exit and uses them as the default settings in your next session.

        • During any particular session, you can revert to the default settings.

        • You can save the current settings to a file.

        • You can import saved settings.

        • You can restore settings to those that were in effect when VR-Forces was first installed (factory settings).

          Dependent settings have two additional options that independent settings do not have:

        • You can save or restore some types of settings by specific setting.

        • You can merge settings from a file into the current settings.

          The procedures for saving and restoring settings are the same regardless of the types of settings. You start the process by clicking a button on a settings dialog box page. The way that VR-Forces saves and restores depends on the type of setting, as follows:

        • When you initiate a save or restore operation on independent settings, it saves or restores all of the settings on the dialog box page from which you started the save or restore. If you have changed a setting on another page, it is not affected.

        • When you initiate a restore operation on dependent settings, related settings may also be restored. VR-Forces displays a message listing the settings that will be restored.

        • When you save dependent settings, you either export all settings of a given type or selected settings. For details, please see relevant sections in Chapter 82, Mapping Models and Effects.

          (Figure 4-10) illustrates the common settings management buttons. (The Visual Model Editors dialog box has some additional buttons. They are explained in Chapter 82, Mapping Models and Effects.)


          image

          Figure 4-10. Settings buttons

          image Revert to the default settings. Override any changes made to settings during this session.

          image Restore the factory settings. Change settings to the settings used when VR- Forces was installed. (The factory settings and default settings may be different.)

          image Import settings from a file. Replace the current settings with those stored in the selected file.


          image

          • Merge in settings from a file. Merging works as follows:

            • Saved settings that do not have a match in the current settings are added.

            • Saved settings replace matching settings.

            • Current settings that are not replaced (that is, for which there is no match in the saved settings) remain valid.

              Figure 4-11 illustrates how merged settings work. Setting A in the saved settings has no match in current settings, so it is added to the merged settings. Current

              settings B2 and C2 are replaced with saved settings B1 and C1. Current setting D has no match in saved settings, so it is retained in the merged settings.


              Saved Settings Current Settings Merged Settings

              image

              Setting A Setting B1 Setting C1


              Setting B2 Setting C2 Setting D

              Setting A Setting B1 Setting C1 Setting D


              Figure 4-11. Merged settings

              image Export all settings to a file. Save the current settings to the selected file.

              image Save the selected setting to a file.


              image

              i

              i


        image


            1. Synchronizing Settings Among VR-Forces Installations

              If your simulation is using several front-ends and back-ends on multiple computers, you may want to use the same settings across all of them, particularly if you have added model definitions and mappings to the factory settings. To synchronize settings, copy the data directories (./appData, ./data, and ./userData) from the computer on which you have updated them to the computers on which the other front-ends and back-ends are installed. Then import the settings into any Settings page that you customized on the source VR-Forces machine.

              Starting VR-Forces — Exiting VR-Forces

              image

            2. Global Settings and Observer-Specific Settings

        VR-Forces has two types of independent settings – global settings and observer-specific settings.

        Global settings affect the display regardless of which observer mode you are using. Global settings include simulation object labels, tactical graphics, and cockpit displays. The settings on the Settings menu are all global settings.

        Observer-specific settings can be different for each observer mode. In fact, given a similar projection and model set, it is the different settings that distinguish one observer mode from another. For example, one difference between Stealth observer mode and Out-the-Window observer mode is that Stealth mode has tactical smoke enabled and Out-the-Window mode has it disabled.


          1. Exiting VR-Forces

            When you exit VR-Forces from the GUI, all GUI windows close. In combined mode, the simulation engine also closes. If you are not running in combined mode, you must also close all simulation engines.

            To exit the VR-Forces GUI, choose File Exit.

            To exit the simulation engine, type q and press Enter.


          2. Configuring Simulation Connections

            A simulation connection specifies the connection parameters for a DIS or HLA simula- tion connection. VR-Forces comes with the following connection configurations:

            • DIS (7) localhost (for use when disconnected from a network or if you do not want to interact with network traffic).

              DIS (7).

            • HLA 1.3 RPR FOM 2.0 with MAK extensions.

            • HLA 1516 Evolved RPR FOM 2.0 with MAK extensions.

        You can edit the supplied configurations or add your own connection configurations that use, for example, a different DIS port or your own FOM Mapper.


            1. Opening the Simulation Connections Configuration Dialog Box

              Simulation connection configurations are maintained in the Simulation Connections Configuration dialog box. This dialog box opens automatically when you start VR- Forces, unless you choose a configuration as the default connection for auto connec- tion. If Auto Connect is enabled and you want to change the connection, you can open the dialog box from the Tools menu.

              To open the Simulation Connections Configuration dialog box, on the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools Configure Connections.

              To start the vrfLauncher on Linux (or from the Windows command line), in a console window, enter the following command:

              vrfLauncher options

              For descriptions of the vrfLauncher command-line options, please see “Command-line Options for vrfLauncher,” on page 5-14.


            2. Adding a Simulation Connection

              When you add a new simulation connection, it has the default values for the protocol that you select. You can then customize it to meet your needs. You can also add new connections by copying an existing connection.

              To add a simulation connection:

              1. On the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools

                Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).


                image


                Figure 4-12. Simulation Connections Configuration dialog box

                image

              2. Click the Add Connection button ( ). The Create Connection dialog box opens (Figure 4-13).


                image

                Figure 4-13. Create Connection dialog box

              3. In the Connection Name box, type a name for the connection.


              4. Select a protocol from the Protocol list.

              5. Click OK.

              6. The connection is added to the list in the Simulation Connections Configuration dialog box.

              7. Select the new connection in the list.

              8. Edit the parameters as desired. They are described in “Simulation Connection Parameters,” on page 4-28.


                Copying a Simulation Connection

                You can create a new simulation connection by copying an existing connection.

                To copy a simulation connection:

                1. On the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools

                  Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).

                  image

                2. Click the Copy Connection button ( ). The Copy Connection dialog box opens.

                3. Accept the default name or type a new name.

                4. Click OK.

                5. Change the connection settings as desired.


            3. Editing a Simulation Connection

              To edit a simulation connection:

              1. On the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools

                Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).

              2. In the list of connections, select the connection that you want to edit.

              3. Edit the parameters as desired. They are described in “Simulation Connection Parameters,” on page 4-28.


            4. Simulation Connection Parameters

              The HLA and DIS simulation connection parameters are equivalent to command-line options for DIS and HLA. Table 4-2 cross references the parameters to their descrip- tions in Chapter 5, Command-line Options.

              Table 4-2: Connection configuration parameters


              image

              Command-line

              Parameter

              DIS

              equivalent Description

              Port -P Specifies the DIS port. “Specifying the Port Number,” on page 5-20.

              Exercise ID -x Specifies the DIS exercise ID. “Specifying the Exercise ID,” on page 5-21.

              Back-end Site Number

              Front-end Site Number

              Back-end Applica- tion Number

              Front-end Appli- cation Number

              -s Specifies the site ID. These values can be the same or different. It is entirely arbi- trary. “Specifying the Site ID and Applica- tion Number,” on page 5-15.

              -a Specifies the application number. The default front-end application number is created by adding 100 to the back-end application number. “Specifying the Site ID and Application Number,” on

              page 5-15.

              DIS Version --disVersion Specifies the DIS version: 4, 5, or 6.

              Default: 6. “Specifying the DIS Version,” on page 5-21.

              Network Inter- face Address

              Destination Address


              Multicast Addresses

              --deviceAddress Specifies the address of the network card

              to use for UDP traffic.

              -A Specifies a specific destination address (point-to-point). “Specifying Point-to-Point or Multicast Operation,” on page 5-20.

              -S Specifies one or more multicast addresses. “Specifying Point-to-Point or Multicast Operation,” on page 5-20.

              Send Buffer Size --sendBufferSize Specifies the send buffer size. Default: -1.

              Receive Buffer Size

              --recvBufferSize Specifies the receive buffer size.

              Multicast TTL --mcastTtl Specifies the multicast time-to-live.

              Default: -1.

              Use Asynchro- nous I/O

              --useAsyncIO Use asynchronous I/O. Default: False.

              Use Absolute Time Stamps

              --useAbsolute- TimeStamps

              Specifies use of absolute time stamps instead of relative time stamps.


              image


              image

              Table 4-2: Connection configuration parameters


              Parameter

              Command-line equivalent

              Description

              Parameter

              Command-line equivalent

              Description


              image

              !

              !

              If you select Use Absolute Time Stamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.


              image


              HLA

              HLA

              image

              Network Inter- face Address

              --deviceAddress The IP address of the host computer.

              Federation Name -x Specifies the name of the federation execution. “Specifying the Federation Execution,” on page 5-17.

              FED File Name -F Specifies the FED file to use. “Specifying the FED File,” on page 5-18.

              Back-end Site Number

              Front-end Site Number

              Back-end Applica- tion Number

              Front-end Appli- cation Number

              -s Specifies the site ID. These values can be the same or different. It is entirely arbi- trary. “Specifying the Site ID and Applica- tion Number,” on page 5-15.

              -a Specifies the application number. The default front-end application number is created by adding 100 to the back-end application number. “Specifying the Site ID and Application Number,” on

              page 5-15.

              RPR FOM Version --rprFomVersion “Specifying the RPR FOM Version,” on

              page 5-18.

              FOM Mapper Library

              -f Specifies the VR-Link FOM Mapper to use. “Specifying a FOM Mapper,” on page 5-18.

              Initialization String

              --fomMapperInit- Data

              Specifies initialization data required by the FOM Mapper, if any. “Specifying FOM Mapper Initialization Data,” on page 5-19.

              Local Settings Designator

              -s Specifies a string that is passed to the RTI during federate connect when using HLA Evolved. It is usually used to provide addi- tional RTI configuration, but every RTI uses it differently. Please consult your RTI documentation for proper usage.

              FOM Modules --fomModules Specifies FOM Modules. (HLA Evolved

              only.)

              Ignore Advisories --useAdvisories Specifies whether or not to use HLA advi-

              sories.

              image


              image

              Table 4-2: Connection configuration parameters


              Parameter

              Command-line equivalent

              Description

              Parameter

              Command-line equivalent

              Description


              Use Absolute Time Stamps

              --useAbsolute- TimeStamps

              Specifies use of absolute time stamps instead of relative time stamps.


              image

              !

              !

              If you select Use Absolute Time Stamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.


              image


              image


            5. Deleting a Simulation Connection

              To delete a simulation connection:

              1. Open the Simulation Connections Configuration dialog box, as described in “Opening the Simulation Connections Configuration Dialog Box,” on page 4-25.

              2. In the list of connections, select the connection that you want to delete.

                image

              3. Click the Delete button ( ). A confirmation prompt opens.

              4. Click Yes.


            6. Configuring Auto Connect

              If you know that you will usually or always want to use the same simulation connec- tion, you can set up Auto Connect and you will not have to select a connection every time you start VR-Forces.

              To configure Auto Connect:

              1. Choose MAK Technologies VR-Forces 4.5 Tools Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).

              2. In the list of connections, select the connection that you want to use every time you start VR-Forces.

              3. Click Set as Auto Connect. A star is displayed next to the selected connection.


                Disabling Auto Connect

                To disable Auto Connect:

                1. Choose MAK Technologies VR-Forces 4.5 Tools Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).

                2. In the list of connections, select the connection that is configured for auto connect.

                3. Click Set as Auto Connect. Auto connect is disabled and the star is removed from next to the connection.


            7. Displaying Connection Information

        You can display connection information while you are running VR-Forces. This may be useful for diagnostic purposes.

        To view connection information, choose Settings Connection Information. The Connection Information dialog box opens (Figure 4-14).


        image

        Figure 4-14. Connection Information dialog box


        4.9. Managing Plug-ins

        One way to extend the functionality of VR-Forces is by loading plug-ins that have been written for it by MAK or other software vendors. You can manage which plug-ins get loaded when VR-Forces starts up. You can also view information about the plug-ins that have been loaded.

        Plug-ins are implemented as one or more dynamic linked libraries (DLL or SO files). The DLLs can be release or debug, for vrfSim or vrfGui, for Windows or Linux, and for a specific protocol or protocol-independent. Each association of an application, plat- form, build type, and transport type is called a configuration. The Plug-ins Editor lets you specify the DLLs to use for each of the desired configurations.


        image

        i

        i

        Changes to plug-in configurations do not take effect until the next time you start the affected VR-Forces application.


        image


            1. Loading Plug-ins

              You can specify which plug-ins to load in either of the following ways:

            2. Adding a Plug-in

              When you add a plug-in, VR-Forces creates an XML file (in ./appData/plugins) that contains all of the information VR-Forces needs to load the plug-in. New plug-ins are added with entries for each of the configurations (application, platform, build type, transport). After you add a plug-in, you must specify the DLLs for each configuration that you want to support.

              To add a plug-in:

              1. Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).

              2. Select the Plug-ins Editor page.

                image

              3. Click the Add button ( ) at the upper right corner of the page (#1 in Figure 4-17). The New Plug-in dialog box opens.

              4. Type a name for the plug-in.

              5. Click OK. The plug-in is added to the Plug-ins list. It has configurations for each of the combinations of application, platform, build type, and transport (Figure

                4-17).


                image

                1 2


                3


                4


                Figure 4-17. New plug-in

              6. Specify the DLL for each configuration that you want to support, as described in “Specifying the DLLs for a Plug-in,” on page 4-35.


            3. Specifying the DLLs for a Plug-in

              Each plug-in configuration that you want to be able to load must specify the DLL to load for that configuration.

              To specify the DLL for a plug-in configuration:

              1. Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).

              2. Select the Plug-ins Editor page (Figure 4-18).


                image

                Figure 4-18. Plug-ins Editor

              3. In the list of plug-ins at the top of the page, select the one that you want to edit.

              4. Click the Plug-in Library column for the configuration that you want to edit. The Select Plugin dialog box opens.

              5. Select the DLL that you want to load for this configuration.

              6. Click Open. The value is changed.


              Removing a Plug-in’s DLL

              You can remove the DLL assignment for a plug-in configuration without removing the configuration.

              To remove the DLL assignment for a plug-in:

              1. Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).

              2. Select the Plug-ins Editor page.

              3. Select the configuration whose DLL assignment you want to remove.

                image

              4. Click the Erase button ( ).


            4. Adding a Plug-in Configuration

              To add a plug-in configuration:

              1. Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).

              2. Select the Plug-ins Editor page.

              3. In the list of plug-ins at the top of the page, select the one that you want to edit.

                image

              4. Click the Add button ( ) above the list of configurations (#3 in Figure 4-17). The Add Plug-in dialog box opens (Figure 4-19).


                image

                Figure 4-19. Add Plug-in dialog box

              5. For each parameter (Application, Platform, Build Type, and Transport), select a value from the list.

              6. Click OK. The configuration is added to the list.

              7. Specify a DLL for the configuration, as described in “Specifying the DLLs for a Plug-in,” on page 4-35.


            5. Deleting a Plug-in Configuration

              To delete a plug-in configuration:

              1. Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).

              2. Select the Plug-ins Editor page.

              3. In the list of plug-ins at the top of the page, select the one that you want to edit.

              4. Select the configuration that you want to delete.

                image

              5. Click the Delete button ( ) that is above the list of configurations (#4 in Figure 4-17).


            6. Deleting a Plug-in

              When you delete a plug-in, you delete the XML configuration file in ./appData/plugins

              that specifies the plug-in configurations and whether or not to load it.

              To delete a plug-in:

              1. Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).

              2. Select the Plug-ins Editor page.

              3. In the list of plug-ins at the top of the page, select the one that you want to delete.

                image

              4. Click the Delete button ( ) to the right of the plug-ins list (#2 in Figure 4-17).


            7. Viewing a List of Loaded Plug-ins

        You can view a list of the plug-ins that are loaded when you start up VR-Forces. Plug- ins may include a description that you can also view.

        To view the details of loaded plug-ins:

        1. Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-20).

        2. Select the Plug-ins Loaded page (Figure 4-20).


          image

          Figure 4-20. Plug-ins dialog box, Plug-ins Loaded page

        3. To view details about a plug-in, select it in the list.

          Starting VR-Forces — The VR-Forces Log Files

          image

          4.10. The VR-Forces Log Files

          On Windows, VR-Forces creates two log files, vrfSim.log and vrfGui.log. Both log files are written to the directory from which you run VR-Forces.

          On Linux, in combined mode, VR-Forces automatically creates a log file, vrfSim.log for back-end output. Front-end output is sent to the console. If you want to view back-end output, open a second console window, and do tail -f vrfSim.log. If you want to send front-end output to log files, or if you are running in separate mode and want to create a log file for either the front-end or back-end, you need to redirect your output to a file, for example:

          vrfGui > vrfGui.log


          image

          1. Command-line Options


            VR-Forces has command-line options for vrfGui and vrfSim.

            Command-Line Options for vrfGui 5-3

            Command-line Options for vrfSim 5-9

            Command-line Options for vrfLauncher 5-14

            Running in Combined Mode from the Command Line 5-15

            Using the -- Command-line Argument 5-15

            Protocol-Independent Command-line Options 5-15

            Specifying the Site ID and Application Number 5-15

            Specifying the Language to Use in the GUI 5-16

            Setting the Notification Level 5-16

            Loading Plug-ins 5-17

            Command-line Options for HLA Federations 5-17

            Specifying the Federation Execution 5-17

            Specifying the FED File 5-18

            Specifying the RPR FOM Version 5-18

            Specifying a FOM Mapper 5-18

            Specifying the RPR FOM Revision 5-18

            Specifying FOM Mapper Initialization Data 5-19

            Specifying a FED File That is Appropriate for the FOM Mapper 5-19

            Enabling Time Management 5-19

            Command-line Options for DIS Exercises 5-20

            Specifying the Port Number 5-20

            Specifying Point-to-Point or Multicast Operation 5-20

            Specifying the Multicast Time-to-Live 5-20

            Using Asynchronous I/O 5-20

            image

            Command-line Options

            Specifying the Exercise ID 5-21

            Specifying the DIS Version 5-21

              1. Command-Line Options for vrfGui

                Table 5-1 lists the command line options for vrfGui.

                image

                Table 5-1: vrfGui command-line options (Sheet 1 of 7)


                Option Description

                Option Description

                (-- | --ignore_rest) Ignore all command-line options after this one. This

                option is useful for disabling part of a command line in a script for test purposes so that you do not have to retype all of the command options at a later point.

                --alphaBits bits Sets the number of alpha bits (0, 8).

                --antiAliasing level Set the anti-aliasing level (0, 2, 4, 8, or 16). Default:

                4.

                --appDataDir directory Specifies the location of application data.

                (-c | --showConsole) Display a console window.

                (-C | --autoConnect)

                {filename | connector_name}

                Automatically connect to the network using the specified connector.

                --dataDir directory Specifies the location of the data directory (terrains

                and so on).

                --defaultSimulationModel- Set sms

                The simulation model set to use as the default when starting up the GUI.

                --depthBits bits Sets the depth of graphics to 24 bits or 32 bits.

                Default: 24.

                --dis Start in DIS mode, using DIS command-line argu- ments to specify connection parameters. DIS- specific arguments do not have to follow --dis; they can be in any order.

                --disableDynamicTerrain Disables the dynamic terrain engine. May slightly

                speed up terrain loading and paging.

                --dispSetting filename Specifies the display engine configuration to load.

                --doNotCheckPluginVersions Do not check the version in a plug-in to make sure it

                can load in VR-Forces. A plug-in gets built against a particular version of VR-Forces. Ordinarily, when VR-Forces loads a plug-in, it checks to be sure it was created with that version of VR-Forces. This option prevents that check.

                --doNotLoadVrfPlugins Prevents loading of plug-ins in the ./plugins direc-

                tory.

                (-e | --extraArgs) string Allows you to send arbitrary strings to the initializer,

                which can be queried for by plug-ins. This option works around the restriction on adding new command-line arguments.

                --enableLogFileTimestamps Print a timestamp for each line in a log file.

                image


                --enableVSync Turns on VSync.

                --entDispSetting filename Specifies the entity display setting to load.

                --entityDefsDir directory Loads the .hier and .leaf files in the specified direc-

                tory.

                --envSetting filename Specifies the environment configuration file to load.

                (-E | --entTypeMap) filename Load the specified object type mapping file. The file

                extension determines the type of mapping.

                --factoryRootDir Set the root directory used to restore settings to factory defaults.

                --fileTransporterReceive- Port port

                Port for the file transporter. This is the port used to receive order of battle and plan files.

                --forceTextShaping Force all text to use HarfBuzz shaping. Use this

                option if you need support for right-to-left languages. It may affect performance.

                --fowPerspective force Shows the ground truth and spot reports perspec-

                tive of the specified force, where force can be Friendly, Opposing, Neutral, or None. Default: None.

                --fullScreen Start with the window in full screen mode.

                --frameRate rate If rate is 0, the frame rate is variable. Otherwise,

                specifies a fixed frame rate for rendering.

                (-G | --locale) language Specifies the locale (for localization).

                --gui filename Specify a GUI configuration file. This file specifies the layout of menus, toolbars, and dialog box pages. A simple filename assumes

                ./appdata/settings/vrfGui. A relative filename is from the ./bin directory. A full path is used as is.

                (-h | --help) Display command-line usage information.

                --highestPriority Changes the priority of the application and the main

                render thread to the highest available priority. This command may starve other processes.

                --hla13 Start in HLA 1.3 mode, using HLA command-line arguments to specify connection parameters. HLA- specific arguments do not have to follow --hla13; they can be in any order.

                --hla1516 Start in HLA 1516 mode, using HLA command-line arguments to specify connection parameters. HLA- specific arguments do not have to follow

                --hla1516; they can be in any order.

                image


                --hla1516e Start in HLA Evolved mode, using HLA command- line arguments to specify connection parameters. HLA-specific arguments do not have to follow

                --hla1516e; they can be in any order.

                (-I | --unbatchedRendering) Disables instance rendering. Default: Enabled.

                (-K | --disableKDTrees) Disable creation of KD trees for intersections.

                (-l | --logFileName)

                filename

                (-L | --loadObservers)

                filename


                --layoutSettingsFile

                filename

                Specifies the log file name.


                Loads the saved observers in the specified file. You can use this command multiple times, for example:

                --loadObservers file1 --loadObservers file2

                Specifies the GUI layout settings file to use. file- name specifies the base filename. It is prefixed with default_ and the extension .uisx is added. Default: UILayoutSettings.

                --loadPlugin filename Specifies a plug-in to load. Accepted multiple times.

                The filename can be a DLL or SO or an XML file that specifies the plug-ins to load. The order in which you list multiple plug-ins on the command line does not determine the order in which they are loaded. For details, please see “Managing Plug-ins,” on page 4-31.

                --loadSimulationObject- Group group


                --mergeEntityTypeMap

                {directory | filename}


                --mergeHierarchyEntityDef

                filename


                --mergeHierarchyTactical- GraphicsDef filename


                --mergeHierarchyUnitDef

                filename


                --mergeLeafEntityDef

                filename

                Creates a new scenario on the simulation object group editing terrain and creates an instance of the simulation object group on that terrain.

                Merges all entity type mapping files (*.metx) in a directory or individual entity type mapping files. Can be used multiple times.

                Merges the specified .hier file into the default hier- archy (usually loaded from ./appData/definitions.) Merging is additive only. No nodes in a previously loaded hierarchy are replaced.

                Merges the specified .hier file into the default hier- archy (usually loaded from ./appData/definitions.) Merging is additive only. No nodes in a previously loaded hierarchy are replaced.

                Merges the specified .hier file into the default hier- archy (usually loaded from ./appData/definitions.) Merging is additive only. No nodes in a previously loaded hierarchy are replaced.

                Merges the specified leaf file into the default entity element definitions.


                image


                --mergeLeafTacticalGraph- icsDef filename

                Merges the specified leaf file into the default tactical graphics element definitions.

                --mergeLeafUnitDef filename Merges the specified leaf file into the default unit

                element definitions.

                --mergeModelDefs {directory

                | filename}


                --mergeTacticalGraphics- TypeMap {directory | filename}


                --mergeUnitTypeMap

                {directory | filename}


                (-n | --notifyLevel)

                notify_level

                Merges all model definition files (*.ommx) in the specified directory or individual model definition files. Can be used multiple times.

                Merges all tactical graphics type mapping files (*.mtgx) in a directory or individual tactical graphics type mapping files. Can be used multiple times.

                Merges all unit type mapping files (*.magx) in a directory or individual unit type mapping files. Can be used multiple times.

                Specifies the notification level for application messages, where notification_level is a number from 0 through 4. The least verbose message level is 0, the highest is 4. The default is 2. For details, please see “Setting the Notification Level,” on page 5-16.

                --noAppDataEntityDefs Do not load the entity element definitions in

                ./appData/definitions.

                --noAppDataTacticalGraph- icsDefs

                Do not load the tactical graphics element definitions in ./appData/definitions.

                --noAppDataUnitDefs Do not load the unit element definitions in

                ./appData/definitions.

                --noAppDataEntityTypeMap Do not load entity type mappings in ./appData/defi-

                nitions.

                --noAppDataModelDefs Do not load model definitions in ./appData/defini-

                tions.

                --noAppDataTacticalGraphic- sTypeMap

                Do not load tactical graphics type mappings in

                ./appData/definitions.

                --noAppDataUnitTypeMap Do not load unit type mappings in ./appData/defini-

                tions.

                --nonVrfObjectsUUIDScheme

                scheme

                Sets the UUID scheme for non VR-Forces objects. Values are entity-identifier, global-identifier, marking-text. Default: entity-identifier.

                (-O | --hasNTPSync) Enables synchronized ocean between different VR-

                Vantage applications, such as VR-Vantage Stealth and the VR-Forces front-end. System clocks must be synchronized.

                --plugin filename Load the specified plug-in. Can be used multiple

                times.


                --pseudoFullScreen Use pseudo full screen for full screen mode. This

                may improve performance when using dynamic ocean.

                --pvd Start the VR-Forces front-end with only 2D modes available.

                (-S | --suppressHatInter- sectOnAttach)

                Suppress the periodic HAT intersection when attached. This setting can improve performance if you need to attach the observer to ground vehicles a lot, but do not need to attach to air vehicles.

                --scenarioFile filename Specifies a scenario to load.

                --stealth Start the VR-Forces front-end with only 3D modes available.

                --stencilBits bits Sets the number of stencil bits (0 or 8). Default: 0.

                terrain_MTF_file Specifies a terrain (MTF) file to load.

                --unplug filename Do not load the specified plug-in. Can be used

                multiple times.

                --useAbsoluteTimeStamps Enables use of absolute time stamps. Otherwise

                uses relative time stamps.


                image

                !

                !

                If you select --useAbsoluteTimeStamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.


                image


                --useFileCommChannel

                channel

                The communication file to be used as a base for communicating text based commands from external applications.

                --userDataDir directory Specifies the user data directory.

                (-v | --version) Display version information and exit.

                (-z | --useReverseZBuffer) Specifies use of reverse Z buffering, which may

                reduce Z-fighting when viewing the terrain from a distance.

                (-Z | --ignoreZoomFor- Disable zoom for SpeedTree LOD.

                image

                SpeedtreeLod

                HLA Only

                These options are available if you specify --hla13,

                --hla1516, or --hla1516e.

                HLA Only

                These options are available if you specify --hla13,

                --hla1516, or --hla1516e.

                (-a | --appNumber) number Application number.

                (-f | --fomMapperLib)

                libname

                (-F | --fedFileName)

                fedfile_name

                FOM Mapper library name. FED file name.

                --fomMapperInitData data FOM Mapper initialization data.

                image


                --fomModules module Specifies an HLA Evolved FOM module. Can be used

                multiple times.

                (-H | --hostAddressString)

                address

                Specifies the host address. This is usually the same as the device address.

                (-i | --sessionId) ID Specifies the session ID for this instance of the

                front-end.

                --ignoreAdvisories Enables or disables HLA advisory messages.

                Default: true.

                --localSettingsDesignator

                designator


                (-N | --federateName)

                federate_name

                Specifies a string that is passed to the RTI during - federate connect when using HLA Evolved. It is usually used to provide additional RTI configuration, but every RTI uses it differently. Please consult your RTI documentation for proper usage.

                Specifies a unique name that can be assigned to the federate. No two federates within the same federa- tion can have the same name. If no name is speci- fied, the RTI will automatically assign a unique name for the federate.

                Default: VR-Forces. (HLA Evolved only)

                (-p | --federateType) type Federate Type can be used to distinguish different

                categories of federates, and its only practical use is in save-and-restore.

                --rprFomRevision RPR FOM revision for RPR FOM 2.0, draft 17.

                --rprFomVersion

                version_number

                RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006,

                2.0014, 2.0017, or 2.0)

                (-s | --siteId ID Site ID.

                --useGeographicDdm Specifies use of geographic DDM if you are using

                the MÄK RTI. Default: false.

                image

                (-x | --execName) exec_name Execution name. Default: MAK-RPR-2.0.


                DIS Only

                These options are available if you specify --dis.

                DIS Only

                These options are available if you specify --dis.

                (-a | --appNumber) number Application number.

                (-A | --destAddrString) Destination address.

                address

                --appIdRange The application ID range for VR-Forces back-ends.

                --defaultObjectTimeout Specifies the timeout interval for objects.

                timeout

                --deviceAddress address Specifies the address of the network card to use for

                UDP traffic.

                --disVersion The DIS version. Default: 7.

                --fileTransporterReceive- The port for the file transporter.

                Port port


                image

                Table 5-1: vrfGui command-line options (Sheet 7 of 7)


                Option Description

                Option Description

                (-H | --hostAddressString)

                address

                Specifies the host address. This is usually the same as the device address.

                (-i | --sessionId) ID Specifies the session ID for this instance of the

                front-end.

                --mcastTtl Specifies the multicast time-to-live. Default: -1.

                --multicastAddresses Specifies one or more multicast addresses.

                address1 ... addressn

                (-P | --disPort) port DIS port.

                --recvBufferSize size Receive buffer size.

                (-s | --siteId ID Site ID.

                --sendBufferSize size Send buffer size. Default: -1.

                --subnetMask mask Specifies a subnet mask.

                --useAsyncIO Use asynchronous I/O. Default: False.

                --useIpv6 Use the IPV6 protocol, if available.

                (-x | --exerciseId) ID Exercise ID.

                image


              2. Command-line Options for vrfSim

                Table 5-2 describes the command-line options for vrfSim.

                image

                Table 5-2: vrfSim command-line options (Sheet 1 of 5)


                Option Description

                Option Description

                (-a | --appNumber)

                application_number


                --additionalSystemScriptsDi- rectory directory

                Specifies the application number. For details, please see “Specifying the Site ID and Application Number,” on page 5-15.

                Specifies a directory where VR-Forces will look for system scripts when it populates the Scripted Task dialog box script list.

                --appDataDir directory Specifies the location of the appData directory.

                --appIdRange lower-upper Specifies a range of application IDs that represent

                objects generated by VR-Forces.

                (-B | --batchScenarioFile- Name) batch_file

                Runs the specified batch file. (For use with one back-end only.) For more information, please see Running in Batch Mode from the Command Line, under “Running VR-Forces in Batch Mode,” on page 7-39.

                (-c | --frontEndPID) PID The process ID for the front-end when running in

                combined mode.


                --countryCodesMappingFile

                file_name


                (-d | --settingsFile)

                file_name

                Specifies an alternative file that maps country codes to country names and DIS enumeration values.

                Specifies a configuration file to load instead of

                vrfSimSettings.xml.

                --daemon Starts that back-end as a daemon process (Linux only). If you start vrfSim as a daemon, it does not try to read characters from the console. It forks a background process at startup. It will exit cleanly if it receives a SITGTERM, SIGQUIT, or SIGINT signal.

                --dataDir directory Specifies the data directory for the back-end.

                --defaultObjectTimeout

                timeout

                --diGuyAnimationsFile

                file_name


                --diGuyCharacterDataFile

                file_name

                Specifies the timeout interval for objects.


                Specifies an additional configuration file for DI- Guy animations.

                Specifies an additional configuration file for DI- Guy character data.

                --disableCallbackQueue Disables all main thread parallel algorithms.

                --disableParallelTick Execute all tick code serially.

                --doNotLoadVrfPlugins Do not load any VR-Forces plug-ins from the

                ./plugins directory.

                --enableChannel channel Enables a specific channel for the channel-specific

                output, even if it is disabled in channelSet- tings.mtl.

                --fileNotifyLevel level Notify level in log file to use.

                --fullyLoadTerrain For paged terrains, load all pages.

                (-h | --help) Displays help information in a console window.

                --hostAddressString address The IP address of the host computer. Called

                Device Address in the Launcher.

                (-i | --sessionId)

                session_ID


                (-L | --scenarioFileName) "scenario_pathname"

                Specifies a session ID. For details, please see “Specifying a Session ID,” on page 4-8.

                Loads the specified scenario. The pathname can be absolute or relative from the ./bin directory. Mutually exclusive with the -T option. For details, please see “Loading a Scenario from the Command Line,” on page 7-18.

                --loadPlugin plugin_file Specifies one or more plug-ins to load. (Accepted multiple times.)

                --logFileName filename Log file to use.


                --logFrameRateStatistics Specifies that the back-end should log frame rate

                statistics.

                --msdlSIDCMappingFile

                file_name


                (-n | --notifyLevel)

                notification_level


                --nonVrfObjectsUUIDScheme

                scheme

                Specifies an alternative file for mapping SIDC codes to DIS enumerations.

                Sets the level for messages written to the console or the VR-Forces log file (vrf.log), where notifi- cation_level is a number from 0 through 4. The least verbose message level is 0, the highest is 4. The default is 2. For details, please see “Setting the Notification Level,” on page 5-16.

                Sets the UUID scheme for non vrf objects. Values are entity-identifier, global-identifier, marking-text.

                --numCallbackThreads threads Number of threads in the callback queue.

                --outputLogFile file_name The file to use to write out application output.

                (-q | --doNotUseConsole) Specifies that all vrfSim output go to the log file

                rather than the console (quiet mode). If you are using a high level of notification, sending output to the console can degrade performance. Running in quiet mode prevents this degradation of perfor- mance. This command only applies to back-ends running on Windows. To create a log file on Linux, redirect the output of vrfSim, for example:

                vrfSim > mylog.txt

                For more details about log files, please see “The VR-Forces Log Files,” on page 4-38.

                (-r | --startInRunMode) Starts the back-end in run mode. If you start the

                back-end without specifying a scenario (with -L) or a terrain database (with -T), the back-end starts in pause mode.

                (-s | --siteId) site_id Specifies the site ID. For details, please see

                “Specifying the Site ID and Application Number,” on page 5-15.

                --setMainThreadToHighPrior- ity

                Sets the VR-Forces main thread to high priority. When enabled, other threads may be starved if there are insufficient processors available. If running on hardware with limited processor time, this may decrease overall system performance. Windows only.

                --simulationModelSet sms Specifies the simulation model set. It must be

                declared separately for front-end and back-end even in combined mode.

                --startMinimized Minimizes the vrfSim console at startup.


                (-T | --terrainDatabase)

                terrain_database

                Specifies a terrain database to load in the back- end. Mutually exclusive with the -L option. For details, please see “Working with Multiple Back- ends,” on page 3-7 and “Loading a Terrain Data- base at Startup,” on page 4-21.

                --targetFrameRate rate Specifies the frame rate above which vrfSim will

                yield CPU time to other processes.

                --useAbsoluteTimeStamps Enables use of absolute time stamps. Otherwise

                uses relative time stamps.


                image

                !

                !

                If you select --useAbsoluteTimeStamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.


                image


                --userDataDir directory Specifies the user data directory for the back-end.

                (-v | --version) version Displays version information.

                --waitQueue Turn off main thread participation in parallel algo- rithms.

                (-- | --ignore_rest)] Ignore all of the command-line options that are

                image

                listed after this argument. This lets you quickly limit the arguments applied if you want to edit a script or batch file without losing the original command line.

                HLA Only

                HLA Only

                (-f | --fomMapperLib)

                libname

                (-F | --fedFileName)

                fedfile_name

                FOM Mapper library name. FED file name.

                --fomMapperInitData data FOM Mapper initialization data.

                --fomModules module Specifies an HLA Evolved FOM module. Can be

                used multiple times.

                --ignoreAdvisories Enables or disables HLA advisory messages.

                Default: true.

                --mimModule Specifies an HLA Evolved MIM module.

                (-N | --federateName)

                federate_name

                Specifies a unique name that can be assigned to the federate. No two federates within the same federation can have the same name. If no name is specified, the RTI will automatically assign a unique name for the federate.

                Default: VR-Forces. (HLA Evolved only)

                --noRtiCompilerCheck Disable RTI Compiler version check.


                (-p | --federateType) type Federate Type can be used to distinguish different

                categories of federates, and its only practical use is in save-and-restore.

                --rprFomRevision RPR FOM revision for RPR FOM 2.0, draft 17.

                --rprFomVersion

                version_number


                (-S | --localSettingsDesig- nator) designator

                RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006,

                2.0014, 2.0017, or 2.0)

                Specifies a string that is passed to the RTI during federate connect when using HLA Evolved. It is usually used to provide additional RTI configura- tion, but every RTI uses it differently. Please consult your RTI documentation for proper usage.

                --timeManagement Enables time management for the back-end.

                image

                (-x | --execName) exec_name Execution name. Default: VR-Link.

                DIS Only

                DIS Only

                (-A | --destAddrString) Destination address.

                address

                --deviceAddress address Specifies the address of the network card to use for UDP traffic.

                --disVersion The DIS version. Default: 7.

                --mcastTtl Specifies the multicast time-to-live. Default: -1.

                (-S | --multicastAddresses) Specifies one or more multicast addresses.

                address1 ... addressn

                (-P | --disPort) port DIS port.

                --recvBufferSize size Receive buffer size.

                --sendBufferSize size Send buffer size. Default: -1.

                --subnetMask mask Specifies the subnet mask. VR-Forces can usually

                figure out the subnet mask from the IP address. However, if it does not do this correctly, you can explicitly specify the subnet mask.

                --suppressSelfReflect Represses self reflection of the DIS exercise

                connection.

                --useAsyncIO Use asynchronous I/O. Default: False.

                --useIpv6 Specifies that the DIS exercise connection use IPV6.

                (-x | --exerciseId) ID Exercise ID.

                image

                Command-line Options — Command-line Options for vrfLauncher

                image

              3. Command-line Options for vrfLauncher

                Table 5-3 describes the command-line options for vrfLauncher.

                image

                Table 5-3: vrfLauncher command-line options


                Option Description

                Option Description

                (-B | --backend) Start vrfLauncher for the back-end only.

                (-C | --config) Open the Simulation Connections Configuration

                tool.

                (-F | --frontend) Start vrfLauncher for the front-end only.

                (-G | --locale) locale Specifies the language to use.

                --guiArgs Arguments after --guiArgs are passed only to the front-end.

                (-h | --help) Displays help information in a console window.

                --simArgs Arguments after --simArgs are passed only to the back-end.

                --usePredefinedConnec- tion connection

                Specify an already defined connection name, such as DIS localhost, so that the vrfLauncher can launch without needing to display the Simulation Connections dialog box.

                (-v | --version) Displays version information.

                -- Pass all arguments after this to vrfGui and vrfSim, except as modified by F-- or B--.

                Special Commands for Arguments that Come After --

                F-- Arguments after F-- are passed only to the front- end.

                B-- Arguments after B-- are passed only to the back- end.

                -debug Appends a “d” to vrfGui or vrfSim to run the debug version. Can only be used following B-- or F--. (Windows only)

                image


                image

                !

                !

                The use of the -- command line option is the opposite of how it is used for other MAK applications.


                image

                Command-line Options — Protocol-Independent Command-line Options

                image

                1. Running in Combined Mode from the Command Line

                  If you want to run VR-Forces in combined mode from the command line, there are no command-line arguments for vrfGui or vrfSim to support this. However, you can run vrfLauncher with the --usePredefinedConnection argument and VR-Forces will load the specified connection without displaying the Simulation Connections Configu- ration dialog box. This has the effect of running directly in combined mode from the command line. For example, suppose you want to start in combined mode using the DIS connection. The command would be:

                  vrfLauncher --usePredefinedConnection DIS


                2. Using the -- Command-line Argument

            The -- command-line argument is used to send additional command-line arguments to the front-end and back-end. This is the opposite of how this argument is used in other MAK applications.

            It has some special sub-arguments that allow you to direct some arguments only to the front-end or back-end. It also has an argument that lets you run vrfGui or vrfSim in debug mode. Figure 5-1 illustrates how these arguments are used.


            vrfLauncher --usePredefinedConnection DIS_1 -- -P 3456 F-- -c B-- -q -debug

            image

            image

            Use predefined connection DIS_1. image

            All arguments after this go to the front-end and back-end unless modified by B-- or F--.

            Send -c to front-end (show console).

            Send -q to back-end (do not use console) and run vrfSimD.


            Figure 5-1. Using the -- command-line argument


              1. Protocol-Independent Command-line Options

                This section describes in greater detail some of the most commonly used command-line options that you can use with both DIS and HLA.


                1. Specifying the Site ID and Application Number

                  Each front-end and back-end must have a unique site ID:application number pair. To specify the site ID, use the -s option. To specify the application number, use the -a option, for example:

                  vrfSimDIS -s 2 -a 3005

                  The default application number for vrfGui is 3000; for vrfSim it is 3001.

                  Command-line Options — Protocol-Independent Command-line Options

                  image

                2. Specifying the Language to Use in the GUI

                  VR-Forces decides which translation files to use based on the language setting for your computer. However, you can override the language setting with the -G command-line option, for example, the following command sets the language to German:

                  vrfGui -s 1 -a 3000 -G de --dis

                  If you use this command-line option, you must have a file named vrf_language_code (for example, vrf_de) in the ./translations directory. For more information, please see “Localizing the Graphical User Interface,” on page 2-10.


                3. Setting the Notification Level

                  You can control the types of messages sent to the console (and log file on a PC) by spec- ifying a notification level.

                  To specify a notification level, use the -n option, for example:

                  vrfSimDIS -s 1 -a 3001 -n 1

                  The notification levels you can specify are:

                  • 0 – Only fatal messages are printed.

                  • 1 – Warning messages and fatal messages are printed.

                  • 2 – Some diagnostic information is printed with warnings and fatal messages.

                  • 3 – Verbose information is printed.

                  • 4 – Debug information is printed. The default notification level is 2.


                    image

                    i

                    i

                    The Linux version of VR-Forces does not have a log file. Informational messages are sent to the window from which you start VR-Forces. To capture informational messages, redirect output to a file.


                    image


                4. Loading Plug-ins

                  You can load plug-ins from the command line or by specifying them in a configuration file. (For details about creating a configuration file, please see “Managing Plug-ins,” on page 4-31.)

                  To load a plug-in from the command line, use the --loadPlugin command-line option, for example:

                  vrfGui -s 1 -a 3000 --loadPlugin pluginA

                  --loadPlugin pluginB --dis

                  vrfSimDIS -s 1 -a 3001 --loadPlugin pluginA

                  --loadPlugin pluginB


                  image

                  !

                  !

                  Do not specify the extension of the plug-in (for example, .dll). If the extension is included, the plug-in will not load.


                  image


                  VR-Forces can display a list of the plug-ins that are loaded. For details, please see “Viewing a List of Loaded Plug-ins,” on page 4-37.


              2. Command-line Options for HLA Federations

                VR-Forces listens to whatever port is specified in the RID file. For information about the RID file, consult your RTI documentation.


                1. Specifying the Federation Execution

                  By default, VR-Forces uses the MAK-RPR2-1-1.fed file and the MAK-RPR-2.0 federa- tion execution.

                  To specify the HLA federation execution name, use the -x option, for example:

                  vrfSimHLA13 -s 1 -a 3001 -x MAK-RPR-2.0

                  --rprFomVersion 2.0 -F MAK-RPR2-1-1.fed


                  image

                  !

                  !

                  If you are using the MAK RTI and are running multiple, concurrent federation executions, you must run the rtiexec. In other words, you cannot use the MAK RTI in lightweight mode if you are running multiple federations. Please see the MAK RTI documentation for details about how to configure it to use the rtiexec.


                  image

                  Command-line Options — Command-line Options for HLA Federations

                  image

                2. Specifying the FED File

                  In combined mode, specifying -F in the command line also applies to the back-end. If you are running a back-end independently and want to specify a FED file name, you must use -F.

                  To specify a FED file at startup, use the -F option.


                3. Specifying the RPR FOM Version

                  VR-Forces has built-in support for the RPR FOM. The default version is 1.0.

                  You can specify a different RPR FOM version (0.5, 0.7, 0.8, 2.0006, 2.0014, 2.0017, or 2.0). If you specify a different FOM version, you must also specify the correct FED file (with -F).

                  vrfSimHLA13 -s 1 -a 3001 --rprFomVersion 2.0

                  -F MAK-RPR2-1-1.fed


                  image

                  i

                  i

                  Please see VR-Forces Release Notes for a list of the RPR FOM versions supported by your version of VR-Forces.


                  image


                4. Specifying a FOM Mapper

                  VR-Forces supports alternative FOMs through the VR-Link FOM Mapper. You can specify which FOM Mapper to use with the -f command-line option:

                  vrfSimHLA13 -s 1 -a 3001 -x MAK-RPR-2.0

                  --rprFomVersion 2.0 -F MAK-RPR2-1-1.fed

                  -f myFomMapper


                5. Specifying the RPR FOM Revision

                  MAK revises FED files when it discovers errors in how it has previously handled various aspects of the HLA standard. It maintains multiple revisions to ensure compatibility with applications that depend on previous revisions.

                  To specify the RPR FOM revision, use the --rprFomRevision revision

                  command-line option, for example:

                  vrfSimHLA13 -s 1 -a 3001 --rprFomVersion 2.0017

                  -F MAK-RPR2-1-1.fed --rprFomRevision 2


                6. Specifying FOM Mapper Initialization Data

                  Some FOM Mappers require initialization data. If you specify a FOM Mapper that requires such data, specify the data with the --fomMapperInitData option:

                  vrfSimHLA13 -s 1 -a 3001 -x MAK-RPR-2.0

                  --rprFomVersion 2.0 -F MAK-RPR2-1-1.fed

                  -f myFomMapper --fomMapperInitData ABC

                  The string “ABC” is passed to the FOM Mapper creation function in the shared library as an initialization parameter.


                7. Specifying a FED File That is Appropriate for the FOM Mapper


                  image

                  !

                  !

                  The -f option only tells the application which FOM Mapper to use. It does not ensure that you are using the right FED file for the FOM Mapper. Make sure that you are using a FED file that is consistent with the FOM Mapper you have chosen.


                  image


                  By default VR-Forces uses a FED file called MAK-RPR2-1-1.fed, but you can specify an alternate FED file using the -F option.

                  The following example instructs the application to use the RPR FOM 2.0, version 17 FOM mapping code, in the federation execution MAK-RPR20017-1-1, with the MAK-RPR20017-1-1.fed file:

                  vrfSimHLA13 -s 1 -a 3001 --rprFomVersion 2.0017

                  -x MAK-RPR20017-1-1 -F MAK-RPR20017-1-1.fed


                8. Enabling Time Management

                  You can enable time management for the back-end from the command line, as follows:

                  vrfSimHLA13 -s 1 -a 3001 --timeManagement

                  -F MAK-RPR1-TimeManagement-1-1.fed

                  -x MAK-RPR1-TimeManagement-1-1


              3. Command-line Options for DIS Exercises

                This section describes command-line options that apply only to using VR-Forces with DIS exercises.


                1. Specifying the Port Number

                  By default, VR-Forces listens to port 3000.

                  To change the port that VR-Forces listens to, use the -P option, for example:

                  vrfSimDIS -s 1 -a 3001 -P 3500

                  vrfGui -s 1 -a 3000 --dis -P 3500


                2. Specifying Point-to-Point or Multicast Operation

                  You can specify that VR-Forces run in point-to-point mode or multicast.

                  To specify point-to-point, use the -A option, for example:

                  vrfSimDIS -s 1 -a 3001 -A 123.123.12.1

                  To specify multicast, use the -S option, for example:

                  vrfSimDIS -s 1 -a 3001 -S 233.233.22.3

                  You can specify more than one multicast address, as follows:

                  vrfSimDIS -s 1 -a 3001 -S address -S address ...


                  image

                  i The default is broadcast mode.

                  image

                3. Specifying the Multicast Time-to-Live

                  The multicast time-to-live specifies the number of routers that a message can pass through when PDUs are sent to multicast addresses.

                  To specify the multicast time-to-live value, use the --mcastTtl option, for example:

                  vrfSimDIS -s 1 -a 3001 -S address -S address --mcastTtl 3


                4. Using Asynchronous I/O

                  If you want to use asynchronous I/O for DIS exercises, start VR-Forces with the

                  --useAsyncIO option. Using asynchronous I/O can help prevent dropped packets and the resulting loss of information. There is no comparable command-line option for HLA. To use asynchronous I/O in HLA, you set a RID file parameter.

                  Command-line Options — Command-line Options for DIS Exercises

                  image

                5. Specifying the Exercise ID

                  To set the VR-Forces exercise ID, use the -x option, for example:

                  vrfSimDIS -s 1 -a 3001 -x 6


                6. Specifying the DIS Version

            To specify the DIS version, use the --disVersion command-line options, for example:

            vrfSimDIS -s 1 -a 3001 --disVersion 6

            Please see VR-Forces Release Notes for a list of supported versions.


            image

          2. Optimizing Performance


        This chapter explains how you can view performance statistics for the front-end and back-end and how you can optimize GUI performance.

        Introduction 6-3

        Optimizing Simulation Engine Performance 6-3

        Optimizing Front-End Performance 6-4

        Monitoring the Back-end Frame Rate 6-5

        Displaying Performance Statistics 6-6

        Displaying the VR-Forces Function Profiler 6-8

        Displaying OSG Statistics 6-8

        Filtering Simulation Objects Using Interest Management 6-8

        Enabling Interest Management 6-9

        Configuring Interest Management 6-9

        Clearing the Model Instancing Cache 6-11

        Miscellaneous Performance Configuration Options 6-12

        Limiting Use of Spot Reports 6-12

        Using Asynchronous I/O for DIS Exercises 6-12

        Using Incremental Compiling with Streamed Data 6-12

        Setting the Tick Rate 6-13

        Specifying the Tick Rate for Components 6-13

        Tuning the Network Interface 6-14

        Tuning the State Repository Tick Rate 6-14

        Configuring Graphics Quality 6-14

        Balancing Visual Quality Against Network Performance 6-15

        Enabling Configuration of Performance Options 6-16

        Trajectory Smoothing 6-16

        image

        Optimizing Performance

        Configuring Trajectory Smoothing 6-17

        Tuning the Target Frame Rate 6-17

        Coloring Draw Calls 6-18

        Configuring VSync 6-19

        DI-Guy Performance Settings 6-19

        image

          1. Introduction

            Optimizing Performance — Introduction

            This chapter describes ways that you can optimize performance through the GUI, the object parameter database, and command line options. You can also optimize perfor- mance programmatically.

            VR-Forces’s overall performance varies based on the following factors:

            • Size of the terrain database.

            • Amount of memory available on your computer.

            • Computer speed and processing power.

            • The number of objects (simulation objects and tactical graphics) in the scenario and how active the simulation objects are.

            • The number of objects you try to simulate on a given back-end.

            • The frequency of the tick rate.

            • The number of front-ends and back-ends you run on your computer.


            1. Optimizing Simulation Engine Performance

              VR-Forces supports the following methods for optimizing the performance of the simulation engine:

            2. Optimizing Front-End Performance

              The performance of the front-end depends on:


          1. Monitoring the Back-end Frame Rate

            You can monitor frame rate statistics for each back-end in your session. The Frame Rate Monitor lists statistics for each back-end (Figure 6-1).


            image

            Figure 6-1. Frame Rate Monitor

            To view the Frame Rate Monitor, choose View Frame Rate Monitor Panel.

            Optimizing Performance — Displaying Performance Statistics

            image

          2. Displaying Performance Statistics

            VR-Forces can display two kinds of performance statistics — OSG statistics (Figure

              1. ), and VR-Forces statistics (Figure 6-3). VR-Forces also has a function profiler that developers can use to assess the performance of new code.



                image

                Figure 6-2. OSG performance statistics


                image

                Performance Statistics Overlay


                Function Profiler Overlay


                Figure 6-3. VR-Forces performance statistics and function profiler

                Optimizing Performance — Displaying Performance Statistics

                image


                image

                i

                i

                Displaying performance statistics may affect performance. Displaying OSG statistics may affect performance more than VR-Forces statistics.


                image


                To display VR-Forces performance statistics:

                1. Choose Settings Display. The Display Settings dialog box opens.

                2. Select the Render Settings page (Figure 6-4).


                  image

                  Figure 6-4. Render Settings page

                3. Select the Show Performance Statistics Overlay check box. A statistics display is added to the window (Figure 6-3).


            1. Displaying the VR-Forces Function Profiler

              The VR-Forces Function Profiler is primarily for the use of developers who are debug- ging VR-Forces applications. For information about how to integrate the profiler into your code, please see Chapter 11, Using the Function Profiler in VR-Forces Developers Guide.

              To run the VR-Forces Profiler:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Render Settings page (Figure 6-4).

              3. Select the Show Function Profiler Overlay check box. A statistics display is added to the window (Figure 6-3).


            2. Displaying OSG Statistics


              image

              i

              i

              If you display OSG statistics and VR-Forces statistics at the same time, they overlay each other.


              image


              To display OSG performance statistics:

              1. Press F2. The frame rate is displayed.

              2. Continue pressing F2. Additional statistics are displayed. When all statistics are displayed, pressing F2 closes the display.


          1. Filtering Simulation Objects Using Interest Management

            VR-Forces can use interest management to improve front-end performance in simula- tions that have high simulation object counts. Interest management is an implementa- tion of HLA data distribution management (DDM). When interest management is enabled, VR-Forces filters out all simulation objects that are more than a specified distance from the observer.

            Optimizing Performance — Filtering Simulation Objects Using Interest Management

            image

            1. Enabling Interest Management

              To use interest management:

              • You must use HLA (DIS does not support interest management).

              • If you are using the MÄK RTI, you must use MÄK RTI 3.4a or later.

              • You must configure your RTI to support DDM. (If you are using the MÄK RTI, you can configure your system to use ddm-rid.mtl, which has DDM enabled.)

                To enable interest management, start vrfGui from the command line and include the --useGeographicDdm command line option with the HLA configuration commands, for example:

                vrfGui -s 1 -a 3004 --hla -x MAK-RPR-2.0

                --rprFomVersion 2.0 -F MAK-RPR2-1-1.fed

                --useGeographicDdm


            2. Configuring Interest Management

              Interest management works by filtering out all simulation objects beyond a specified distance from the observer. You can configure this distance (DDM region size) and you can configure the threshold for observer movement (region update threshold) before VR-Forces recalculates which simulation objects should be displayed.

              VR-Forces uses a geographic DDM scheme. The earth is divided into two dimensional regions, with X pointing north and Y pointing east. When you specify a DDM region size, you specify the length of one side of a region.

              The region update threshold is a percentage of the distance from the center of the region to a side. When the observer moves beyond the threshold, the region is recalcu- lated. For example, if the region size is 1000 meters, the distance from the center to a side is 500 meters. If the region update threshold is 50%, when the observer moves more than 250 meters from the center of the region, VR-Forces recalculates the display region.

              DDM regions use a two-dimensional grid, so the altitude of the observer is not consid- ered when filtering simulation objects. However, in 3D observer modes, you usually cannot see entity models once the observer is a certain distance above the terrain (although you can see labels). Therefore, you may want to filter out simulation objects based on the observer’s altitude, thereby increasing performance.

              To configure interest management:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Interest Management Settings page (Figure 6-5).



                image

                Figure 6-5. Interest Management Settings page

              3. In the DDM Region Size box, type a value for the region size.

              4. In the Region Update Threshold box, type a value, as a percentage, for the update threshold.

              5. Optionally, filter simulation objects based on the observer’s altitude, as follows:

                1. Select the Hide Entities When Observer’s Altitude is Above check box.

                2. Specify the observer altitude at which to hide simulation objects.

              6. Click OK.

              Optimizing Performance — Clearing the Model Instancing Cache

              image

                1. Clearing the Model Instancing Cache

                  VR-Forces has a feature called model instancing that lets models share resources, such as geometry and textures. These shared resources are stored in a cache. Use of model instance caching decreases memory use and improves performance.

                  You can clear the model instancing cache if you need the disk space.

                  To clear the model instancing cache:

                  1. Choose Settings Application. The Application Settings dialog box opens.

                  2. Select the File Caching Settings page (Figure 6-6).


                    image

                    Figure 6-6. File Caching Settings page

                  3. Click Clear Instancing Cache.

                    Optimizing Performance — Miscellaneous Performance Configuration Options

                    image

                2. Miscellaneous Performance Configuration Options

              You can improve front-end performance by limiting use of display features, as follows:

              • Turn off track histories.

              • Limit use of object transparency.

              • Limit use of spot reports.

              • In DIS, use asynchronous I/O.

              • For streamed data, use incremental compiling.


            1. Limiting Use of Spot Reports

              Use of spot reports can degrade performance. You may want to limit the number of simulation objects for which they are generated or disable spot reports entirely. You can also specify that spot reports be sent only to the front-end. For details about using spot reports, please see “Displaying Simulation Objects Based on Spot Reports,” on

              page 9-2.


            2. Using Asynchronous I/O for DIS Exercises

              By its nature, DIS generates a lot of network traffic. Therefore, you may experience problems with dropped packets and simulation objects may time out. You can mitigate this problem by using asynchronous I/O. To use asynchronous I/O, start with the

              --useAsyncIO command line option or select Use Asynchronous I/O in the Simula- tion Connections Configuration dialog box.


            3. Using Incremental Compiling with Streamed Data

        Users of streamed terrains might want to consider using incremental compiling. This is an OSG option that allows the processing of streamed data to be spread across multiple frames, reducing performance spikes. To use it, create the environment variable OSG_ICO. (It does not need a value. It just needs to exist.)


        image

        i

        i

        Using OSG_ICO may cause LOD issues with other paged formats. It is only recommended for streamed terrains.


        image


        image

          1. Setting the Tick Rate

            Optimizing Performance — Setting the Tick Rate

            VR-Forces lets you tune performance by varying the tick rate of components, state repositories, and network interfaces. By decreasing the frequency with which some simulation object components are ticked, you make more CPU time available to other simulation objects. For example you could decrease the tick rate for slow moving enti- ties such as dismounted infantry entity or a command post, making more CPU avail- able for entities such as aircraft or missiles.

            Variable tick rates are determined by a minimum tick period and a minimum tick period variance. The minimum tick period parameter specifies the shortest period of time, in seconds, that can elapse between ticks of a simulation object’s components. VR-Forces may tick the components less frequently (due to heavy CPU load), but it will never tick the entity’s components more frequently than specified.

            To reduce the frequency that a component can be ticked, increase the minimum tick period value. To increase the frequency that a component can be ticked, reduce the minimum tick period value.

            The minimum tick period variance argument specifies an amount of variance allowed around the minimum tick period. Specifying a minimum tick period variance value helps prevent the spikes in CPU usage that would result if all components tried to tick at the same time. Calculation of the time to tick a component using minimum tick period variance is as follows (the example uses the entity component arguments):

            If the current time is t0 and the next scheduled tick is tnext then:

            tnext = t0 + min-tick-period +/- rand(min-tick-period-vari- ance/2)

            If you insert some sample values (in seconds), you get:

            tnext = .1 + .05 +/- rand(.05/2)

            This means that the next tick will be no sooner than the current time plus .15 seconds plus or minus a random value between 0 and .0125 seconds.


            image

            i

            i

            If the next tick time calculated by this formula is less than the current tick time, it is set to the current tick time, which results in the component being ticked on the next tick.


            image


            1. Specifying the Tick Rate for Components

              In the object parameter database, you can specify a min-tick-period and min-tick-period-vari- ance for each simulation object and for individual simulation object components. The component-level settings, if any, override the simulation object-level settings. You can update these parameters in the OPD Editor.

              Optimizing Performance — Configuring Graphics Quality

              image

            2. Tuning the Network Interface

              You can tune the local and remote network interface subcomponents. Specify the net- interface-min-tick-period and net-interface-min-tick-period-variance parameters in the local and remote subcomponents blocks. If you reduce the rate at which the network interfaces are ticked, you can limit how often VR-Forces needs to do coordinate system conver- sion from network (geocentric) to database coordinates.


              image

              i

              i

              Reducing the frequency with which you tick network interface components could delay the discovery of objects in remote front-ends and back-ends.


              image


            3. Tuning the State Repository Tick Rate

        You can tune the frequency with which state repositories get ticked. Specify the state- repository-min-tick-period and state-repository-min-tick-period-variance parameters in the local and remote subcomponents blocks. These parameters control how often VR-Forces recomputes the bounding volume of an object based on object geometry.


          1. Configuring Graphics Quality

            VR-Forces has command-line options that let you configure graphics quality. Depending on the capabilities of your graphics card, you may need to adjust the default settings for anti-aliasing, graphics depth, and stencil buffers. The command-line options are:

            • --antiAliasing level. Anti-aliasing is a technique used to reduce the jagged edges of digital graphics. You can set the level to 0, 2, 4, 8, or 16. Default: 4.

            • --depthBits depth. The number of bits in an image determines its quality and the number of colors it supports. You can set the depth to 24 or 32. Default: 24.

            • --stencilBits bits. The stencil buffer can be set to 0 or 8. Default: 8.

            • --alphaBits bits. Specifies the number of alpha bits – 0 or 8.

              On older graphics cards, you may need to set anti-aliasing to 0 to improve performance.

              Depending on your graphics card and driver, some combinations of these settings may be incompatible. For example, if you set stencil bits to 8, the depth must be set to 24 and anti-aliasing may need to be set to 0 or 2.

              Optimizing Performance — Balancing Visual Quality Against Network Performance

              image

          2. Balancing Visual Quality Against Network Performance

            VR-Forces allows you to tune performance by adjusting dead-reckoning thresholds. The primary benefit of this feature is to improve the appearance of entities in 3D visu- alization programs such as VR-Vantage Stealth and the VR-Forces Stealth observer mode. Reducing thresholds improves the accuracy of entity movement and reduces jumpy movement. However it does so at the expense of network performance, because a lower dead-reckoning threshold results in more packets being sent for each entity.

            When you change thresholds at runtime, VR-Forces sends a message to all back-ends in the scenario to change their default thresholds for translation and rotation. The new thresholds remain in effect until the back-ends are closed. They apply to any scenario run during this time and they override thresholds set in

            ./appData/settings/vrfSim/vrfSimSettings.xml. Changes to the default thresholds get saved

            in vrfSimSettings.xml.

            If your exercise sends periodic updates, such as a DIS heartbeat, the thresholds evaluate changes since the most recent heartbeat.

            Changes made at runtime have no effect in the following cases:

            • If a back-end joins the scenario after the thresholds are sent. It uses the default VR- Link thresholds, or the values in the vrfSimSettings.xml file, if specified.

            • If an object was instantiated with a customized VR-Link DtThresholder.

        To configure performance options:

        1. Choose Settings Application. The Application Settings dialog box opens.

        2. Select the Performance Options page (Figure 6-7).


          image image

          Figure 6-7. Performance Options page

        3. Adjust the Visual Quality slider to your desired preference for visual quality versus network performance.

        4. To have VR-Forces calculate the smoothing period, select Override Smoothing Period. To specify the smoothing period yourself, select Use Specified Smoothing Value and use the slider to set the smoothing period you want to use.

        Optimizing Performance — Trajectory Smoothing

        image

        6.9.1. Enabling Configuration of Performance Options

        The dr-allow-gui-overrides configuration parameter, specified in each OPE file, determines whether a given entity type can have its translation and rotation thresholds overridden by the value set by the Performance Options page.


          1. Trajectory Smoothing

            From the time VR-Forces receives a state update message for a simulation object until it receives the next update, it calculates the location of the simulation object based on the heading and acceleration in the most recent state update. This process is called dead- reckoning. When the next state update arrives for the simulation object, VR-Forces moves it to the new position. If the actual position is significantly different from the dead-reckoned position, the simulation object could appear to jump from the dead- reckoned position to the actual position. VR-Forces can eliminate these discontinuities by smoothing trajectories and rotation paths.

            image

            Figure 6-8 illustrates dead-reckoning and smoothing.


            Dead-

            reckoned

            position

            Updated position

            Updated position

            Dead-

            reckoned

            position


            Last update

            image

            image

            image

            Frames 1-5 Frame 6+ Frame 6+ without smoothing with smoothing


            Figure 6-8. Dead-reckoning and smoothing

            The smooth period is the period of time over which smoothing takes place. The default period is 1/10 second. If course corrections appear abrupt with this setting, you may want to increase the smooth period.


            image

            i

            i

            Smoothing makes fast-moving entities, such as fixed wing aircraft, look better. Slow moving entities, such as dismounted infantry, may look worse. If your simulation is mostly one or the other of these types of entities, enable or disable smoothing as appropriate for the best visualization experience.


            image

            Optimizing Performance — Tuning the Target Frame Rate

            image

            1. Configuring Trajectory Smoothing

              To configure trajectory smoothing:

              1. Choose Settings Application. The Application Settings dialog box opens.

              2. Select the Performance Options page (Figure 6-7).

              3. Select the Use Specified Smoothing Value option. The Enable Smoothing check box becomes enabled.

              4. To enable or disable smoothing, select or clear the Enable Smoothing check box.

              5. To change the smooth period, adjust the Smoothing Period slider or type a value, in seconds, in the box.


          1. Tuning the Target Frame Rate

            The --targetFrameRate command line option and vrfSim.mtl parameter allow you to specify the mean frame rate above which the VR-Forces back-end should begin to sleep in order to give up CPU time to other processes. This parameter is only applicable to variable frame mode; the fixed frame modes already have a built in sleep that gives up unused time. Increasing the target frame rate will only prevent the back-end from sleeping if it cannot achieve that rate – ultimately it is up to the operating system to determine how much CPU time each process receives.

            Optimizing Performance — Coloring Draw Calls

            image

          2. Coloring Draw Calls

            One of the factors that affects performance is the number of draw calls it takes to render a scene. VR-Forces lets you color the draw calls in a scene so that you can see which objects may be creating performance problems.

            When you color draw calls, all the drawables in the scene are randomly colorized. The colors themselves do not convey any meaning. The important information is the number of draw calls required for a model. For example, if a vehicle has 25 different colored parts, you know that it requires 25 draw calls and you may want to edit the model to use fewer of them.

            Figure 6-9 illustrates a tank with its drawables colorized.



            image

            Figure 6-9. Colorized drawables on tank

            The colors do not update as new information comes into the scene. Therefore, you can refresh the colorization.

            To visualize draw calls:

            1. Choose Settings Display. The Display Settings dialog box opens.

            2. Select the Render Settings page (Figure 6-4).

            3. Select the Colorize Per Drawable check box.

            4. To refresh the display, click Refresh.


              image

          3. Configuring VSync

            Optimizing Performance — DI-Guy Performance Settings

            VSync (vertical synchronization) synchronizes VR-Forces’s frame rate with your monitor’s refresh rate. This prevents a visual anomaly called tearing, in which parts of two frames of data can be visible at the same time, but it caps the maximum render frame rate based on the display. Typically this cap is 60hz.

            In some cases, if the frame rate cannot quite keep up with the refresh rate, VSync can force the frame rate to a noticeably lower rate. To avoid this problem, we recommend that you enable triple buffering for your video card. You must do this in the video card’s configuration application; VR-Forces cannot do this for you.

            By default, VSync is disabled. If you want to ensable it, startup with the

            --enableVSync command-line option, or you can configure your video card to force it to be on.


          4. DI-Guy Performance Settings

            The following settings affect performance of DI-Guy human characters:

            Optimizing Performance — DI-Guy Performance Settings

            image


            To specify DI-Guy performance settings:

            1. Choose Settings Display. The Display Settings dialog box opens.

            2. Select the DI-Guy Settings page (Figure 6-10).


              image

              Figure 6-10. DI-Guy Settings page

            3. To set the maximum draw distance, adjust the Max Draw Distance slider or change the value in the box.

            4. Optionally, select or clear the Use Multi-threaded Update check box.

            5. Optionally, select or clear the Enable Instancing check box.

            6. If instancing is enabled, adjust the Instancing LOD slider or change the value in the box.

            7. Optionally, select or clear the Visualize Instancing check box.


        image

      2. Scenarios


        Whenever you use VR-Forces, you work in the context of a scenario. A scenario consists of everything that needs to be specified to run a VR-Forces simulation. Each scenario has a scenario file (.scn) and the following supporting files:

      3. Simulation Objects


        The chapters in this section explain how to add simulation objects to a scenario, how to select them, and how to display information about them.



        VR-Forces Users Guide

        Section III - Simulation Objects


        III-1



        Section III - Simulation Objects

        III-2 VT MAK


        image 15. Introduction to Simula- tion Objects


        Simulation objects are the entities and units that VR-Forces simulates as part of a scenario.

        Simulation Objects 15-2

        How Simulation Objects are Identified 15-3

        UUIDs 15-3

        Simulation Object Names 15-4

        Echelon IDs 15-4

        Object IDs 15-4

        Labels 15-5

        How Simulation Objects are Organized 15-6

        How Echelon IDs are Assigned 15-7

        How Simulation Objects Communicate 15-7

        External Communication Model 15-7

        Custom Communication Models 15-8

        VR-Forces Uses a Component Architecture 15-8

        Sensors 15-9

        Controllers 15-9

        Actuators 15-9

        Simulation Object Behaviors and Tasks 15-10

        Entity-Level Modeling and Aggregate-Level Modeling 15-10

        Introduction to Simulation Objects — Simulation Objects

        image

          1. Simulation Objects

            The players in a simulation are called simulation objects. There are two broad classes of simulation objects:

          2. How Simulation Objects are Identified

            VR-Forces identifies simulation objects by UUID (universal unique ID), name, echelon ID, object ID, and label. Table 15-1 summarizes the characteristics of each type of identifier.

            image

            Table 15-1: Simulation object identifiers


            Identifier Characteristics

            Identifier Characteristics

            UUID Unique. Assigned by VR-Forces.

          3. How Simulation Objects are Organized

        All simulation objects simulated by VR-Forces exist in the context of a hierarchy. At the top-most level, simulation objects are grouped according to force ID (friendly, opposing, neutral, and so on). At lower levels, simulation objects are grouped according to military organization, in which a simulation object has a designation in the hier- archy, such as 2nd Platoon, B Company. At each echelon level in the organization, a simulation object has a single superior simulation object. Disaggregated units contain one or more subordinate entities, units, or both. The hierarchy’s lowest level contains an individual entity.


        image

        i

        i

        In entity-level scenarios, units can be in an aggregated state or a disaggregated state. For details, please see “Units in Entity-Level Scenarios,” on page 22-2.


        image


        Each simulation object has an echelon ID in the following format:

        designator [category] [echelon], designator [category] [echelon], ...,

        force_number Force

        where:

        designator is a number or letter that differentiates the simulation object from other members of the echelon, such as 1 (M1A1), 2 (M1A2), and so on.

        category is an optional descriptor for the simulation object, such as M1A2.

        echelon is an optional descriptor for the organizational unit, such as “Platoon”.

        force_number is the force the simulation object belongs to, based on the force type enumerations. The force is the highest level in the hierarchy.

        When you create a new simulation object, it exists only within the default force. There- fore its echelon ID would be similar to:

        1. M1A2, 1 Force

          If a simulation object becomes part of a unit, the unit information becomes part of the echelon ID, and the designator may change, for example:

        2. M1A2, 2 Plt, 1 Force

        Introduction to Simulation Objects — How Simulation Objects Communicate

        image

        15.3.1. How Echelon IDs are Assigned

        The category and echelon labels that make up an echelon ID, such as “M1A2”, “Plt”, and so on, are specified in the VR-Forces object parameter database and are associated with object-types. When you create a simulation object of a certain type, the echelon ID category and echelon name associated with that type are assigned to the simulation object. You cannot change the labels interactively. You can change the labels by editing the object parameter database.

        Designators are assigned by VR-Forces. You have no direct control over them. When you create new simulation objects, they are assigned designators sequentially, starting with one (1). If you aggregate a group of entities, the unit leader is assigned the desig- nator 1, and the other entities in the unit are assigned successive designator numbers.


          1. How Simulation Objects Communicate

            VR-Forces includes a default communication model called simple-radio-comm-model. Using this simple communication model, radio messages always reach their intended destination (as long as the destination is on a reachable network), and messages are all passed instantly. The simple radio communication model has one parameter, which determines how the radio networks are set up. There are three connection-modes avail- able:

            • aggregate mode specifies that each unit has its own radio network. Messages sent from a simulation object can reach any simulation object that is in the same organization, at the same level (the simulation object’s peers in the organization), and can also reach the simulation object’s direct superior. All other simulation objects are outside the network, and are unable to receive messages sent by the simulation object. This is the default mode.

            • force mode specifies that there is a radio network for each force in VR-Forces. Messages sent from a simulation object can reach any other simulation object of the same force.

            • all mode specifies that all simulation objects in VR-Forces are part of one large radio network. In this case, any simulation object can receive messages sent by any other simulation object.

        The communication model is configured in ./data/simulationModel- Sets/<sms>/CommModelParams.mtl. For details about configuring radios, please see “Configuring Radios,” on page 74-4.


            1. External Communication Model

              VR-Forces includes an external communication model that can communicate with an external communication effects server to determine how to deliver radio messages. For details, please see Chapter 13, Using a Communications Effects Server.

              Introduction to Simulation Objects — VR-Forces Uses a Component Architecture

              image

            2. Custom Communication Models

        You can create new communication models and install them in VR-Forces. This is useful if you want to define your own connectivity model, or write your own algo- rithms for determining if radio messages get delivered. For details, please see API docu- mentation.


          1. VR-Forces Uses a Component Architecture

            image

            VR-Forces simulation objects use a component architecture similar to that used in many robotics applications. There are three basic types of components supported: sensors, controllers, and actuators. Components communicate with each other through data ports and port groups, which may provide data as simple as a single number (such as a throttle value) or more complex data such as a list of simulation objects that have been detected. The port groups make it possible to multiplex and prioritize multiple data sources to a single data recipient. For example, the automotive actuator of ground vehicles can receive inputs from a collision-avoidance controller, move-to-point controller, and follow-route controller, but it does not want inputs from all of those controllers at once.


            Simulation Object

            Simulation Object


            Sensor

            Controller


            Actuator

            Sensor

            Controller


            Actuator



            Entity State

            Entity State


            Figure 15-1. Simulation object component architecture

            The component architecture supports any number of sensors, controllers, and actuators in a simulation object. Components are specified in the object parameter database by using component descriptors. Component descriptors indicate the type of component that should be created. They can also provide parameter information to a component.

            For more information, please see Appendix C, Object Parameters.

            Introduction to Simulation Objects — VR-Forces Uses a Component Architecture

            image

            1. Sensors

              Sensor components provide models of the simulated environment, which are used by controller components to make decisions and perform tasks. The simplest sensor might provide (simulated) ground truth, while more sophisticated ones could use complex models for sensing electromagnetic emissions, RADAR, or a cognitive model to simu- late a soldier or crew member's perception of the simulated world. Sensor components can get information from:

              • The virtual network.

              • From a terrain database.

              • By monitoring the state of the simulation object model.

              • Many other potential sources. The use of sensors is optional.

            2. Controllers

              Controller components typically provide control inputs to actuator components (although this is not required). Controllers can use information provided by sensors to perform their functions, but this is not a requirement either. For example, the controller that implements the various forms of the Wait task neither requires sensor information, nor provides control inputs to any actuators.


            3. Actuators

              Actuator components:

          2. Simulation Object Behaviors and Tasks

            A behavior is something that a simulation object knows how to do on its own. Behav- iors describe how a simulation object reacts to a specific condition or situation or how it performs a task. A task is something that you tell a simulation object to do. A simula- tion object does not innately know that it should move to a point. However, if you task it to move to a point, it knows how to locate the point and how to move to it.

            Behaviors can override task assignments. For example, if an entity is moving along a route and detects another entity in its path, the collision-avoidance behavior overrides the movement task until the entity successfully avoids the obstacle and can return to moving along the route.

            VR-Forces has behavioral models for the included simulation object types. These models simulate the behaviors you would expect from live participants and objects functioning in the real world. You can change the parameters for the behavior models. With the VR-Forces toolkit, you can change the models themselves and add additional models. For more information, please see VR-Forces Developers Guide.


            image

            i

            i

            No semi-automated forces (SAF) system, such as VR-Forces, can completely emulate the behavior of a complex real world entity. The behaviors provided by VR-Forces handle the lower level activities necessary to complete a task, and allow you to focus on the higher level activities involved in assigning tasks and preparing plans.


            image


          3. Entity-Level Modeling and Aggregate-Level Modeling

        VR-Forces supports two different approaches to modeling simulation objects – entity- level simulation and aggregate-level simulation.

        In entity-level simulations, VR-Forces focuses on the interaction among individual entities, such as ships, tanks, automobiles, airplanes, and people. When you create a simulation object, you are usually creating one tank, one ship, or one human, and so on. Combat takes place between entities based on their weapon systems and their ability to withstand munitions.

        In an entity-level simulation, you can combine entities into higher echelon units, such as platoons and companies, but when they engage in combat, they do so by modeling the interactions of their members at the individual entity level.

        Aggregate-level simulations focus on the high level movement and interaction of large numbers of personnel and equipment in hierarchical units. For the most part, they do not model individual simulation object interactions and combat. When you create a simulation object, you are usually creating a company, or a brigade, and so on. Aggre- gate-level combat is modeled based on the relative strengths and weaknesses of simula- tion objects in personnel, equipment, and location, not on the engagement of individual entities.

        Introduction to Simulation Objects — Entity-Level Modeling and Aggregate-Level Modeling

        image


        As in entity-level simulations, in an aggregate-level simulation, you can combine enti- ties and units into higher echelon units.

        The type of modeling used in a scenario depends on the systems that simulation objects use, which are configured in the simulation model set it uses. If you use EntityLevel.sms or an SMS similar to it, it uses entity-level modeling. If you use AggregateLevel.sms, or an SMS similar to it, it uses aggregate-level modeling. Therefore, when you create a scenario, you must consider which type of modeling you want to use and you must remember which type of modeling you are using when you populate the scenario.

        Aggregate-level modeling only works with HLA Evolved and MAK FOM extensions. (If you try to create a scenario with AggregateLevel.sms and you are using an unsup- ported protocol, VR-Forces displays an error message.) For a detailed discussion of the aggregate warfare model, please see Chapter 23, How Aggregate-Level Modeling Works.


        image

        i

        i

        AggregateLevel.sms has some simulation objects that represent individual entities. However, they use data-driven models that are different from those used by similar entities in EntityLevel.sms.


        image


        image

        !

        !

        Although it is possible to create a scenario that uses both types of simulation model sets, the resulting behavior will be unpredictable, because simulation objects that use aggregate-level modeling cannot interact with simulation objects that use entity-level modeling. Combining these SMSs is not recommended and not supported.


        image

        Introduction to Simulation Objects — Entity-Level Modeling and Aggregate-Level Modeling

        image


        image 16. Creating and Placing Objects


        This chapter describes generic procedures for creating and placing simulation objects and tactical graphics. The later chapters assume that you are familiar with these proce- dures.

        Creating Objects 16-3

        Selecting the Object to Create 16-4

        Selecting the Object to Create on an Object Palette 16-5

        Selecting the Object to Create on the Create Menu 16-8

        Draw Mode 16-9

        Placing Objects 16-11

        Placing an Object Using Default Values (Click to Create) 16-11

        Specifying an Object’s Properties Before You Create It (Click to Locate) 16-13 Specifying an Object’s Altitude 16-14

        Setting Altitude Dynamically 16-15

        Setting Altitude in the Create Object or Edit Object Dialog Box 16-15

        Specifying the Altitude for All of the Vertices in a Route 16-16

        Specifying an Object’s Heading Dynamically 16-17

        Locking the Mouse to the Object Being Created 16-18

        Moving Objects 16-19

        Dragging an Object to a New Location 16-19

        Copying and Pasting Objects 16-21

        Copying Objects 16-21

        Pasting Objects 16-22

        Pasting Specific Entity Characteristics 16-23

        Simulation Object Groups 16-25

        Creating Random Versions of Similar Entity Types 16-25

        image

        Creating and Placing Objects

        Creating Cultural Features 16-26

        Creating Props 16-26

        Adding an Object to the Favorites List 16-27

        image

          1. Creating Objects

            Creating and Placing Objects — Creating Objects

            VR-Forces lets you create simulation objects, cultural features, tactical graphics, and props. You can create simulation objects and cultural features from the Create menu or the Simulation Objects Palette. You create tactical graphics from the Create menu or the Tactical Graphics and Hazards/Obstacles palettes. You create props from the Props Palette. The procedure for creating an object is essentially the same regardless of the type of object:

            1. Select the object that you want to create.

            2. Specify the location and properties of the object.

              However, there are several ways to select the object you want to create and several ways to specify an object’s location and properties. This chapter describes the different generic ways to create objects. Additional procedures specific to different object types are described in later chapters.

              When you create an object, VR-Forces adds a tab to the right side of the window, below the object palettes. The tab is labeled Create object, where object is whatever object you selected to create. If you click that tab, it opens a dialog box that lets you specify the properties of the object you are creating. Table 16-1 lists the properties that you can set for each object type. You can also edit these same properties after you create an object.

              Table 16-1: Editable object properties


              Entity

              Cultural Feature

              Tactical Graphic

              Prop

              Force

              X

              X

              X

              Heading

              X

              X

              Label (and extended labels)

              X

              X

              Location

              X

              X

              X

              X

              Name

              X

              X

              X

              Overlay

              X (Edit only)

              X (Edit only)

              X

              Style

              X


          2. Selecting the Object to Create

        You can select the object to create on the Create menu or on an object palette (Simula- tion Objects Palette, Tactical Graphics Palette, Hazards/Obstacles Palette, or Props Palette). Once you have selected the object, placing the object is the same regardless of how you started the process. For details, please see “Placing Objects,” on page 16-11.

        The Create menu does not contain the full list of objects configured in VR-Forces. It only lists the simulation objects and tactical graphics that you have marked as “Favor- ites”. It gives you quick access to your most frequently used objects. For details, please see “Adding an Object to the Favorites List,” on page 16-27.


            1. Selecting the Object to Create on an Object Palette

              VR-Forces has the following object palettes that let you quickly choose the object that you want to create:

            2. Selecting the Object to Create on the Create Menu

              Waypoints, routes, areas, and objects marked as Favorites are available on the Create menu.

              To select the object to create on the Create menu:

              1. If you are using multiple simulation engines, in the Selected Simulation Engine Toolbar select the simulation engine on which you want to simulate the object.

              2. To create an object or graphic, choose Create category object_type, where:

              3. Create the object, as described in “Placing Objects,” on page 16-11.


            3. Draw Mode

        When you create an object, the cursor changes to draw mode. If you are creating a simulation object or a cultural feature in the 2D view, the cursor changes to a 2D icon that represents the chosen simulation object(Figure 16-4).


        image

        Figure 16-4. 2D entity creation and Create object tab

        In the 3D view, the cursor changes to the 3D model for the chosen entity (Figure 16-5). If you are zoomed out, 3D models may be hard to see. If you are creating multiple human characters of a type that randomizes the appearance of the character that gets created, such as Civilian Male, after each character you create, the model attached to the cursor changes to show you the appearance of the next character that will be created.


        image image

        Top-down view as in Figure 2-1 Ground-level view


        Figure 16-5. 3D entity creation

        If you are creating a tactical graphic, the cursor displays the waypoint symbol when you create a point and a vertex symbol when you create any type of line or area. Figure 16-6 illustrates tactical graphics draw mode cursors.


        image image

        Figure 16-6. Tactical graphics cursors in draw mode

        If you are creating a prop, the cursor changes to show the model for the prop. In the 2D view, the model is a top down view and is proportional to the terrain, so it may be diffi- cult to see if you are zoomed out.


          1. Placing Objects

            After you select the object that you want to create, the Create Object tab is added to the right side of the window below the Props Palette.

            There are two basic methods for placing simulation objects, as follows:

          2. Specifying an Object’s Altitude

        You can specify an altitude for air platforms, sub-surface entities, the vertices of waypoints and routes, and props when you create them or edit their properties. (You can also set altitude for simulation objects using the Location set data request, Fly Alti- tude tasks, and the Move to Location task. You can set altitude dynamically or in the various dialog boxes for setting object properties or actions.)

        Creating and Placing Objects — Specifying an Object’s Altitude

        image

            1. Setting Altitude Dynamically

              You can set altitude dynamically for simulation objects that support an altitude, for waypoints, for individual vertices of a route, and for props that have not been saved into a terrain. When you set altitude dynamically, it is set relative to the terrain.

              To set altitude dynamically:

              • If you are creating an object, press and hold Alt and scroll the mouse wheel, or press and hold Alt+left mouse button and drag the mouse.

              • If you are editing a simulation object or vertex:

                1. Double-click the object to make it editable.

                2. Press and hold Alt and scroll the mouse wheel, or press and hold Alt+left mouse button and drag the mouse.

                3. Click to set the new altitude.


            2. Setting Altitude in the Create Object or Edit Object Dialog Box

              When you set altitude in a dialog box, you have the following options:

            3. Specifying the Altitude for All of the Vertices in a Route

              When you create a route or edit its vertices, you may want to change the altitude of all of its vertices in a similar way. VR-Forces lets you:

              • Adjust all vertices by the same amount.

              • Set all vertices to the same height above sea level.

              • Set all vertices to the same height above the terrain.

        To change the altitude for all of the vertices in a route:

        1. If you are creating a route, open the Create Route dialog box. If you are editing a route:

          1. Select the route.

          2. Choose Objects Edit. The Edit Route dialog box opens.

        2. Click the Adjust Points button ( image). The Adjust All Points dialog box opens (Figure 16-8).


          image

          Figure 16-8. Adjust All Points dialog box

        3. Select the adjustment action as follows:

          • Adjust Altitude By. Changes the altitude of each vertex by the amount specified in the Altitude box.

          • Set Altitude Above Sea Level. Sets the altitude of each vertex to the amount above sea level specified in the Altitude box. This could result in some vertices being below ground.

          • Set Altitude Above Terrain. Sets the altitude of each vertex the amount above the terrain specified in the Altitude box.

        4. Type the desired altitude adjustment value in the Altitude box.

        5. Click OK.

        Creating and Placing Objects — Specifying an Object’s Heading Dynamically

        image

          1. Specifying an Object’s Heading Dynamically

            When you create a simulation object, cultural feature, or prop, you can set its heading in the Create Object dialog box, or dynamically. Afterwards, you can edit a simulation object or cultural feature’s heading directly or use the Heading set data request. (For more information, please see “Heading,” on page 34-23.)

            To set an object’s heading dynamically as part of the creation process, hold down the Shift key and the left mouse button, and drag the mouse.


            image

            i

            i

            In the 2D view, as you change the heading for a simulation object you can see the heading indicator change heading. However cultural features do not have heading indicators, so if you want to set the heading dynamically, you may want to switch to 3D view so that you can see the model rotate.


            image

            Creating and Placing Objects — Locking the Mouse to the Object Being Created

            image

          2. Locking the Mouse to the Object Being Created

            By default, when you create simulation objects or waypoints, you can create multiple objects by continuously left-clicking without exiting create mode. This is a very conve- nient feature if you want to create objects using default naming conventions and do not need to specify specific location coordinates or overlay assignments during the creation process. (You can always edit an object’s properties after you create it.)

            However, if you want to use the Create Object dialog box to specify location or other properties for each object as you create it, this feature can be inconvenient because as you move the mouse to the Create Object dialog box, the placement location changes with the mouse movement. Disabling this feature can give you greater control over the creation process, because clicking to set the location of the object or a vertex does not create it – it sets the coordinates, but lets you make further changes in the Create Object dialog box before you create the object.

            If you disable an object’s attachment to the mouse when you are creating objects, you create them by clicking Create in the dialog box rather than clicking on the terrain.

            To enable or disable the mouse’s attachment to the creation location, in the Create Object or Edit Object dialog box, select or clear the Attach Object to Mouse check box (Figure 16-9). When you clear the check box, a Create button gets added to the dialog box. The setting gets carried over to future object creations.


            image

            Figure 16-9. Create Object dialog box


            image

          3. Moving Objects

            Creating and Placing Objects — Moving Objects

            You can move an object by dragging it, changing its location in the Edit dialog box, or for simulation objects only, sending a Location request.

            For information about setting the location of a simulation object, please see “Location,” on page 34-26.


            image

            i You can only move objects simulated by VR-Forces.

            image

            1. Dragging an Object to a New Location

              When you move objects, they are centered on the mouse location as follows:

        Creating and Placing Objects — Moving Objects

        image


        image

        Figure 16-11. Moving multiple objects


        image

        i

        i

        If you click the terrain and then Shift+click or Ctrl+click an object, the terrain is selected and the Move command will not be available.


        image


        To drag an object from one point on the terrain to another:

        1. Double-click the object, or select the object and choose Objects Move.

        2. Move the mouse to change the location of the object.

        3. Left-click the mouse.


        image

        i You can drag multiple objects and they can be of different types.

        • To drag multiple objects, you must select the objects and choose

        Objects Move.


        image


        Canceling a Drag-and-Drop Move

        To cancel a move made by dragging an object, press Esc before you click the left mouse button.


          1. Copying and Pasting Objects

            You can copy objects and paste the copies elsewhere in a scenario or even in another scenario. The Paste Special option allows you to specify which entity characteristics you paste.

            VR-Forces copies the following data about an object:

            • Environmental objects:

              • Original name.

              • Label.

              • Force.

              • Color.

            • Entities:

              • Original name.

              • Label.

              • Force.

              • Heading.

              • Appearance (lights, landing gear, and so on).

              • Rules of engagement.

              • Plan.

            • Units copy the same information as entities plus the list of subordinates. VR-Forces does not copy:

            • The current task.

            • State information, except as noted previously.

            • Load balancing status. All objects get pasted into the currently selected back-end.

            • Embarkation structures. If, for example, you copy an aircraft carrier that has planes embarked, only the carrier is copied, not the embarked entities.


        image

        !

        !

        The copy/paste process is resource intensive. It is primarily for use during scenario development. Use during a simulation could affect performance.


        image


            1. Copying Objects

              To copy objects:

              1. Select the objects you want to copy.

              2. Choose Objects Copy.


            2. Pasting Objects

              A simple paste pastes all of the attributes of an object that get copied. It pastes objects as follows:

              • Tactical graphics are placed on the currently selected overlay. If you copied objects that were on different overlays, that differentiation is not preserved.

              • Copied objects maintain the state at the time that they were copied. Therefore, if you paste objects some time after they were initially copied, the copies do not reflect any changes that may have taken place to the original simulation objects. For example, if a simulation object was copied and then deleted, the copied version of the entity is still pasted.

              • Embarkation structures are not copied, only the parent entity.


              image

              !

              !

              Pasting plans may have unexpected consequences, because their object references do not change when you copy them. For example, suppose the plan for Entity A refers to Waypoint 1. You copy Entity A and Waypoint 1 and paste them as Entity B and Waypoint 2. If you copy the plan, Entity B’s plan will still refer to Waypoint 1. If you expected it to refer to Waypoint 2, you will not see the behavior you expected. You can choose not to paste plans. For details, please see “Pasting Specific Entity Characteristics,” on page 16-23.


              image


              To paste objects:

              1. Choose Objects Paste. The objects in the paste buffer are displayed on screen. They float as you move the cursor to show you where they will be placed when you paste them.

              2. Click on the terrain where you want the objects to be pasted. They are pasted in the relative positions in which they were copied. If an object has an altitude, it is pasted using the same altitude above the terrain as the original object.

              3. Optionally, continue pasting additional copies if desired.

              4. Right-click to exit paste mode.


            3. Pasting Specific Entity Characteristics

              When you paste simulation objects, you can specify which of the following entity char- acteristics you want to paste with the entity:

              • Plans.

              • Appearance.

              • Heading.

              • Rules of engagement.

              • Entity name.

              • Altitude. You can specify that the previous altitude be applied as above terrain or as above sea level.

              To paste particular entity characteristics:

              1. Choose Objects Paste Special. The Paste Special dialog box opens.


                image

                Figure 16-12. Paste Special dialog box

              2. By default, all check boxes are selected. Clear the check boxes for the options you do not want to paste.

              3. Choose the altitude option that you want to use.

              4. Click OK. The objects in the paste buffer are displayed on screen. They float as you move the cursor to show you where they will be placed when you paste them.

              5. Click on the terrain where you want the objects to be pasted. They are pasted in the relative positions in which they were copied.

              6. Optionally, continue pasting additional copies if desired.

              7. Right-click to exit paste mode.


        Pasting Altitude

        When you paste objects, if the pasted object can have an altitude value, such as a fixed- wing entity, a waypoint, or the vertices of a route, the default behavior is to replicate the original altitude above the terrain. If you use the Paste Special operation, you can choose to apply the original altitude as being above sea level. Figure 16-13 illustrates these alternatives. A waypoint is placed on the terrain. It is 0 meters above the terrain. However, the terrain itself is 200m above sea level. If the waypoint is copied and pasted at point A and the altitude above the terrain is maintained, the point is placed at 0m above the terrain. If the point is pasted at point B and altitude above sea level is main- tained, it is placed 200m above sea level.


        image

        Original


        200m


        image

        Copy


        A B


        Figure 16-13. Pasting altitude

        Creating and Placing Objects — Creating Random Versions of Similar Entity Types

        image

          1. Simulation Object Groups

            Simulation object groups (SOG) are a convenient mechanism for creating reusable configurations of simulation objects and tactical graphics. You create them in the Simu- lation Object Editor and they are listed on the Simulation Objects Palette with other simulation objects. VR-Forces places them in the relative positions that you specified when you created the SOG. VR-Forces includes example SOGs, including a carrier group, a Patriot missile battery, and a barracks with several soldiers. These examples demonstrate SOGs with tactical graphics, cultural features, and embarkation.


            image

            i

            i

            The Barracks With Guards SOG has some tactical graphics, but they are hidden by default. To see them, click the overlay icon at the bottom of the window, or select the check box on the Objects List Panel, Overlays tab.


            image


            The Simulation Objects Palette has a category for SOGs (Object Group), but like other simulation objects, they can be in multiple categories. SOGs can be distinguished from other simulation objects in the lists because the object name includes the number of objects in the group.

            For information about creating SOGs, please see “Creating a Simulation Object Group,” on page 65-45.


          2. Creating Random Versions of Similar Entity Types

            VR-Forces has many different models for generic types of entities, such as a civilian vehicles or commercial aircraft. When you are creating a scenario with these sorts of entities, you can choose the specific entity types you want to use. However, if you want to quickly populate a scenario with a variety of similar objects, it is simpler to just let VR-Forces randomly create instances of the generic entity. This is done using the random simulation object.

            A random simulation object is configured in the Simulation Object Editor with a list of specific simulation object types that it can draw from. When you create a scenario, you choose the random entity type on the Simulation Objects Palette and when you click on the terrain to place the object, VR-Forces picks a specific simulation object from the list.

            The random simulation objects provided with VR-Forces are:

            • Civilian vehicle.

              You can add your own random simulation objects in the Simulation Object Editor.

              Creating and Placing Objects — Creating Cultural Features

              image

          3. Creating Cultural Features

            Cultural features are objects that you can add to a scenario to simulate human artifacts such as buildings, bridges, and so on. They are in the Building and Cultural Feature categories on the Create menu and the Simulation Objects Palette. You add them to a scenario the same way you would add a simulation object. Cultural features are listed in the Objects List Panel. You can apply some set data requests to them, such as Location and Heading.


            image

            !

            !

            Some of the choices on the cultural feature lists are the same as those available on the Props Palette. However, cultural features are not the same things as props. Props are terrain objects and can be saved as part of a terrain. Cultural features are not part of the terrain, they are a type of simulation object and are saved in the order of battle file.


            image


          4. Creating Props

            Props are terrain objects that you can select independently of the terrain. “Extracting Props from a Terrain Patch,” on page 55-20 explains how to create them by extracting them from a terrain or a feature layer. However, you can also create them from the Props Palette, similarly to how you create simulation objects. This is a valuable feature if your terrains do not have any features that you can extract as props. However note the following important details:

          5. Adding an Object to the Favorites List

        As mentioned in “Selecting the Object to Create,” on page 16-4, the Create menu does not include all of the objects that you can create. It just lists the objects that you have designated as “Favorites”. When you specify that a simulation object or tactical graphic be a favorite, it is automatically added to the Create menu.

        The favorites list is specific to a simulation model set. It is saved to ./data/simulation- ModelSets/<model_set>/gui/favorites.mst. You can copy the file to other instances of VR- Forces or future releases and your favorites list will be enabled.

        To add or remove an object from the Favorites list:

        1. Open the palette that has the object you want to add to the Favorites list.

        2. Select the category for the object you want to add to the Favorites list.

        3. Click the star to the left of the object’s name.

        Creating and Placing Objects — Adding an Object to the Favorites List

        image


        image 17. Selecting Objects


        This chapter describes ways to select simulation objects and tactical graphics.

        The Objects List Panel 17-2

        Selecting Simulation Objects, Tactical Graphics, and Props 17-4

        Selecting Objects in the Window 17-5

        Selecting Objects in the Objects List Panel 17-6

        Selecting a Simulation Object in the Object Console Summary Panel.. 17-6 Unselecting Objects 17-7

        Using Selection Groups 17-7

        Creating a Selection Group 17-8

        Selecting a Selection Group 17-9

        Adding Objects to a Selection Group 17-10

        Removing Objects from Selection Groups 17-10

        Renaming a Selection Group 17-10

        Deleting a Selection Group 17-10

        Selecting Objects — The Objects List Panel

        image

          1. The Objects List Panel

            There is a great deal of similarity in how you select, move, and view the different types of objects. You can manage them on the terrain, to some extent from the keyboard, and in the Objects List Panel, which is the central repository of object information.

            The Objects List Panel has the following views:

          2. Selecting Simulation Objects, Tactical Graphics, and Props

            VR-Forces displays the following kinds of objects that you might want to select:

            • Simulation Objects. Any of the entity and unit types that you can create.

            • Cultural features. Objects in the Building and Cultural Feature categories on the Simulation Objects Palette.

            • Tactical graphics. Control objects and the points, lines, areas, text, and symbols on the Tactical Graphics Palette, Hazards/Obstacles Palette, and Create menu.

            • Props. Any of the props that you can create from the Props Palette or which are already part of the terrain.

        You can select all types of objects in the window. You can select simulation objects, cultural features, and tactical graphics in the Objects List Panel (Figure 17-1). You can select simulation objects in the Object Console Summary Panel, and you can select props on the Props page of the Terrain Settings dialog box (Figure 17-4).


        image

        Figure 17-4. Terrain Settings dialog box, Props page

        When you select a simulation object or tactical graphic in the 2D view, its border color changes to white. In the 3D views, all selected 3D objects display a bounding box (Figure 17-5). Tactical graphics change to white lines.


        image


        2D 3D


        Figure 17-5. Selected objects


            1. Selecting Objects in the Window

              To select objects in the window, use any of the following mouse actions:


              image

              Mouse Action Result

              image

              Click the object. Selects an object (and unselects any other selected

              objects).

              Ctrl-click the object. Selects an object while keeping existing selections. Double-click the object. Selects the object and makes it editable. This is the equiv-

              alent of selecting an object and choosing

              Objects Edit.

              Alt-drag a bounding box.

              Selects multiple objects by dragging a selection box around them.

              Right-click the object. If no objects are selected, right-clicking selects an object

              and displays a menu.

              If one or more objects are selected, right-clicking a selected object maintains the selection and displays a menu. Right-clicking an unselected object changes the selection to the object you right-clicked.

              image


              When you select an object in the window, the views on the Objects List Panel add a gray highlight to the entry for the object to indicate that it is selected.


            2. Selecting Objects in the Objects List Panel

              To select an object in the Objects List Panel:

              1. Select a view in the Objects List Panel (Figure 17-1).

              2. Locate the object you want to select. You can filter the list to make it easier to find particular objects. (For details, please see “Filtering the Object Lists,” on

                page 17-6.) Disaggregate and expand units if necessary. (For details, please see “Expanding and Collapsing Units,” on page 25-2 and “Triggering Unit State Tran- sitions,” on page 24-11.)

              3. Click the entry for the object. The selected object is highlighted in the Objects List Panel and on the terrain.

              4. Optionally, select multiple objects, as follows:

            3. Selecting a Simulation Object in the Object Console Summary Panel

              The Object Console Summary Panel lists messages that have been sent to simulation objects from the simulation engine, from a simulation object’s plan, from other simula- tion objects, and from scripts. (For information about the Object Console Summary Panel, please see “Configuring Object Console Messages,” on page 18-31.)

              To select a simulation object in the Object Console Summary Panel:

              1. Right-click a message from the simulation object you want to select.

              2. On the popup menu, choose Select Entity.


            4. Unselecting Objects

        To unselect objects in the window, choose one of the options in Table 17-1.

        image

        Table 17-1: Unselecting objects on the terrain


        Action Result

        Action Result

        Click in the window away from the selected object or objects.

        Unselects all objects.

        Right-click. Exits edit mode, but object remains selected.

        Click a selected object. If multiple objects were selected, unselects all

        except the object you clicked.

        Ctrl-click a selected object. Unselects the object. If multiple objects were

        selected, does not unselect other objects.

        image


        To unselect objects on the Objects List Panel, choose one of the options in Table 17-2.

        image

        Table 17-2: Unselecting objects in the Objects List Panel


        Action Result

        Action Result

        If one object is selected. Ctrl-click the object.

        If a group of objects is selected:

        image

        Ctrl-click an object. Unselects the object without affecting other selections. Click an object. Selects the clicked object and unselects all other objects.


        17.3. Using Selection Groups

        Selection groups are named subsets of the objects in an exercise. Their purpose is to allow you to quickly select specific objects without needing to locate them on the map or the Entity List in the Objects List Panel and select them individually. Using selection groups can be helpful if you want to quickly select a group of objects that do not fit neatly into the default filter options on the Objects List Panel tabs, for example a mix of friendly and opposing forces and tactical graphics. The group definitions are saved and loaded as part of the scenario.

        An object can be in multiple selection groups.


            1. Creating a Selection Group

              You can create selection groups in any of the following ways:

            2. Selecting a Selection Group

              When you select the objects in a selection group, they are selected in the views on the Objects List Panel and in the display window.

              To select a selection group, use one of the following methods:

              • In the Selection Groups view, select a selection group in the Group list.

              • Choose Objects Selection Groups Select Selection Group group_name, where group_name is one of the groups listed on the pull right menu.

              • If selection groups named with the format Selection Group number exist, pressing a number key selects the corresponding selection group. (The keypad numbers do not support this operation.)


            3. Adding Objects to a Selection Group

              To add objects to a selection group:

              1. Select the objects you want to add to a selection group.

              2. Do one of the following:

                • Choose Objects Selection Groups Add To Selection Group group_name, where group_name is one of the groups listed on the pull right menu.

                  image

                • On the Selection Groups view, click the Add Current to Selection Group button ( ).


            4. Removing Objects from Selection Groups

              There are two ways to remove an object from a selection group. If you remove all the objects from a selection group, the group continues to exist.

              To remove an object from a selection group:

              1. Select the objects you want to remove from a selection group.

              2. Choose Objects Selection Groups Remove from Selection Group

              group_name, where group_name is one of the groups listed on the pull right menu.

              To remove an object from a selection group in the Selection Groups view:

              1. Select the selection group from which you want to remove an object.

              2. Select the object you want to remove.

                image

              3. Click the Remove Selected from Selection Group button ( ).


            5. Renaming a Selection Group

              To rename a selection group:

              1. In the Selections Group view, double-click the name of the group you want to rename. It becomes editable

              2. Type a new name for the selection group.

              3. Press Enter.


            6. Deleting a Selection Group

        Deleting a selection group does not delete the objects from the scenario. However, if you delete all the members of a selection group, the selection group also gets deleted.

        To delete a selection group:

        1. In the Selections Group view, select the group you want to remove.

          image

        2. Click the Delete button ( ).


        image

        18. Viewing Information about Objects


        This chapter describes how to get information about simulation objects.

        Displaying Information About an Object 18-3

        Information Dialog Boxes for Entity-Level Scenarios 18-3

        Information Dialog Boxes for Aggregate-Level Scenarios 18-6

        Information Dialog Boxes for Tactical Graphics 18-8

        Viewing Information for Multiple Objects 18-9

        Displaying Entity Labels 18-9

        Displaying Text Labels for 3D Models 18-12

        Turning Entity Labels On and Off 18-13

        Pinning 3D Text Labels to the Window 18-13

        Displaying Labels for 2D Icons 18-14

        Configuring Shadowing and Background Color for 2D Labels 18-16

        Using Extended Labels 18-17

        Adding an Extended Label 18-18

        Changing an Extended Label’s Index 18-19

        Deleting an Extended Label 18-19

        Simulation Object Icons 18-20

        Changing the Size of 2D Icons 18-21

        Rotating 2D Icons to a Simulation Object’s Heading 18-22

        Displaying HAT Lines for Entities (3D Only) 18-23

        Displaying Threat and Sensor Range Rings 18-24

        Enabling and Disabling the Display of Range Rings 18-26

        Pinning Range Rings for a Simulation Object 18-26

        Configuring the Display of Range Rings 18-27

        Displaying Entity Resources 18-29

        image

        Viewing Information about Objects

        Viewing Numerical Resource Data 18-29

        Displaying Bounding Volumes 18-30

        Showing Bounding Volumes Only for Selected Simulation Objects ... 18-31 Configuring Object Console Messages 18-31

        Setting the Notification Level for Console Messages 18-32

        Viewing All Console Messages 18-33

        Answering Questions from Scripted Tasks 18-34

        Saving Console Messages 18-35

        Displaying an Object Console Warning Icon 18-35

        Clearing the Object Console 18-35

        Viewing Object Counts 18-36

          1. Displaying Information About an Object

            You can display information about individual objects, including entities, units, environ- mental objects, and Stealths. You cannot edit this information. You can also display entity labels. For details about entity labels, please see “Displaying Entity Labels,” on page 18-9.

            To display an object information dialog box:

            1. Select an object.

            2. Choose Objects Information, or press i.


        image

        i You can also open the Information dialog box as follows:

        • Select a message in the Objects Console Summary Panel and choose

          Information on the popup menu.

        • Click any field in the summary panel to open the relevant dialog box page.

        • Click the Information button image) on the Last Selected Object Panel to open the State Data page.

        • Click the current task on the Last Selected Object Panel to open the Information dialog box to the Tasks page.


        image


            1. Information Dialog Boxes for Entity-Level Scenarios

              An information dialog box in an entity-level scenario (Figure 18-1) has the following sections:

            2. Information Dialog Boxes for Aggregate-Level Scenarios

              An information dialog box for units in an aggregate-level scenario (Figure 18-3) has the following sections:

              • Summary:

                • Simulation object icon.

                • Simulation object name.

                • Current task.

                • Sensor information.

                • Posture.

                • Health status.

                • Health and weapon status gumballs.

              • Detailed information.

              • Object console.


                image

                Figure 18-3. Information dialog box for simulation object in aggregate-level scenario

                The summary section for units in aggregate-level scenarios (Figure 18-3) includes gumball icons that display information about the health of the simulation object. Simu- lation object icons also display gumballs.


                Figure 18-4 describes the status represented by different gumball states.



                image

                image No problems

                image Some problems

                image

                Major problems


                Personnel Ammunition Weapons

                POL (fuel)


                image

                Unable to complete mission

                Green: 85% or better Yellow: 70 - 84%

                Red: 50 - 69%

                Black: less than 50%

                White: Not applicable or no information


                Figure 18-4. Gumball charts

                Figure 18-5 illustrates gumball charts for a simulation object icon.


                image

                Figure 18-5. Icon with gumballs

                You can expand and contract the detailed information and object console sections to manage the amount of screen space used by the dialog box.

                The Detailed Information section for simulation objects in aggregate-level scenarios has the following pages:

                • Tasks.

                • State Data.

                • IFF.

                • Subordinates. Lists the subordinates.

                • Personnel and Equipment. The types of personnel and number of each. Casualties, by category.

                • Supplies. Food, water, fuel, and ammunition. The Supplies tab displays informa- tion when a simulation object is receiving supplies or providing them to another simulation object. When a simulation object is receiving supplies, an up arrow is displayed next to the supply it is receiving.

                • Combat Capability. Combat power by category (anti-air, anti-personnel, and so on) and defensive capability, by category.

                • Engagements. Current attack and defense status.


              • Sensor Information. The Sensors tab shows information about simulation objects being detected. The Jamming tab shows if the simulation object is being jammed (electronic warfare) or is jamming other simulation objects.

              • Emitters.

              • Acoustics.

              • Embarkation.


            3. Information Dialog Boxes for Tactical Graphics

              The detailed information section for an environmental object (Figure 18-6), such as a route, has the following pages:

            4. Viewing Information for Multiple Objects

        You can select multiple objects and view summary information for all of them. From the summary information window, you can jump directly to an object and you can open its Information dialog box.

        To view information about multiple objects:

        1. Select the objects.

        2. Choose Objects Information, or press i. The Multiple Object Information window opens (Figure 18-7).


          image

          Figure 18-7. Multiple Object Information window

        3. To zoom to the extents of an object, click its icon.

        4. To open an Information dialog box for an object, click any of the details about the object, such as its name.


          1. Displaying Entity Labels

            VR-Forces provides extensive information about simulation objects in the Information dialog box (“Displaying Information About an Object,” on page 18-3). It also provides an abbreviated set of information in the form of simulation object labels.

            For 3D models, VR-Forces displays labels that help you locate and identify entities (Figure 18-8). The label consists of a locator circle, which is always visible when labels are enabled, and a text label that is displayed when you mouse over an entity. All entities within the view have locator circles, whether the model is visible or not. The color of an entity’s label represents its force – blue for friendly, red for opposing, and green for neutral.


            A 3D text label displays the entity’s:


        image

        i

        i

        If spot reports are enabled, you can display labels for spot reports. For details, please see “Displaying Labels for Spot Reports,” on page 9-9.


        image


        image

        Figure 18-9. Label for a 2D icon


            1. Displaying Text Labels for 3D Models

              To view a 3D text label, use one of the following methods:

            2. Turning Entity Labels On and Off

              To turn the display of entity labels on or off:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Entity Display Settings page (Figure 18-10).

              3. Select or clear the Show Entity Labels check box.


              image

              image

              i

              i

              You can also enable and disable entity labels by choosing Settings Entity Labels or by clicking the Entity Labels button ( ) on the Display Settings Toolbar.


              image


            3. Pinning 3D Text Labels to the Window

              You can pin 3D text labels to the window, making them stay visible after you move the cursor away from the entity.

              To pin a 3D text label to the window or hide a pinned label:

              1. Right-click an entity’s locator circle. A menu is displayed.

              2. Choose Toggle Pinned Label.


                Pinning Multiple 3D Text Labels

                You can display multiple text labels at one time.

                To pin multiple text labels use either of the following methods:


            4. Displaying Labels for 2D Icons

              You can enable and disable the display of labels for 2D icons by label type. This allows you to control how much screen space is taken up by the labels. You can control the display of labels in the Display Settings dialog box or on the Display Settings Toolbar.

              To enable and disable display of 2D icon labels:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Symbol Decoration Settings page (Figure 18-11).


                image

                Figure 18-11. Symbol Decoration Settings page

              3. Select the check box for each label that you want to display. Clear the check box for each label that you want to hide.


                Changing the Color for 2D Labels

                The labels for 2D icons use the color specified by the Foreground Color setting on the Symbol Decoration Settings page. You can also specify that labels use the force color.

                To change the color of 2D labels:

                1. Choose Settings Display. The Display Settings dialog box opens.

                2. Select the Symbol Decoration Settings page (Figure 18-11).

                3. To set the color to any color:

                  1. Click the Foreground Color color swatch. A color picker dialog box opens.

                  2. Select the color you want to use.

                  3. Click OK.

                4. To use the force color for labels, select the Color by Force Type check box. This setting overrides the Foreground Color setting.


              Enabling 2D Labels on the Display Settings Toolbar

              The Entity Labels button on the Display Settings Toolbar lets you open a panel that lists the symbol decorations that you can show or hide. It also lets you color labels by force type.

              To enable or disable 2D labels on the Display Settings Toolbar:

              1. Click the arrow on the Entity Labels button image). A small panel is displayed. It is a persistent window.


                image

                Figure 18-12. Symbol Decoration Panel

              2. Select the symbol decorations that you want to display. Clear the ones you want to hide.

              3. To hide the Symbol Decorations Panel, click the arrow on the Entity Labels button.


            5. Configuring Shadowing and Background Color for 2D Labels

        2D labels are drawn on a background that, by default, is transparent. However, you can increase the opacity of the background to make it visible and can change the back- ground color.

        You can add shadowing to the text of 2D labels. This may improve visibility when simulation objects are on light colored terrain.


        image

        Figure 18-13. 2D label with background

        To set the color and opacity of the 2D label background:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Symbol Decoration Settings page (Figure 18-11).

        3. To change the opacity of the background, adjust the Background Opacity slider.

        4. To change the color of the background:

          1. Click the Background Color color swatch. A color picker opens.

          2. Select the color you want to use for the background.

          3. Click OK.

        To configure shadows for 2D labels:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Symbol Decoration Settings page (Figure 18-11).

        3. Select or clear the Shadow Text check box.


        18.3. Using Extended Labels

        One of the ways to identify a simulation object is by its label. (For more information, please see “Labels,” on page 15-5.) Extended labels are additional labels that you can specify on an application-wide basis and define individually for simulation objects. The contents of each label gets sent over the network as part of the simulation object’s infor- mation and is displayed in its Information dialog box.

        You can add and remove extended labels and change the label name. Changing a label’s name does not affect the text that is associated with the label for those simulation objects that use the label.


        image

        i

        i

        Extended labels are not scenario-specific. They affect all scenarios. Therefore, if you change a label’s name or index, or delete it, be sure that you want this change to apply to all scenarios in which you use the extended label.


        image


        Figure 18-14 shows an extended label (called A Special Label) added in the Application Settings dialog box, Session Options page. Figure 18-15 shows the text for the extended label for a specific entity entered in the Edit dialog box and then displayed on the screen.



        image

        Figure 18-14. Extended label added to session

        Viewing Information about Objects — Using Extended Labels

        image


        image

        Figure 18-15. Extended label text for a simulation object

        You can display extended labels in Plan View mode the same as other symbol decora- tions. For more information, please see “Displaying Labels for 2D Icons,” on

        page 18-14.


            1. Adding an Extended Label

              To add an extended label:

              1. Choose Settings Application. The Application Settings dialog box opens.

              2. Select the Session Options page (Figure 18-14).

                image

              3. Click the Add button ( ) on the Extended Labels line. A label is added to the list window. It has a generic name (for example, Label 1).

              4. Double-click the label name to make it editable.

              5. Type the name you want for this label.

              6. Edit simulation objects to specify the text for this label.


            2. Changing an Extended Label’s Index

              A label’s index is used to store the label text and identify it when sent over the network. In Edit dialog boxes, extended labels are listed in indexed order. You can change an extended label’s index. However, while changing an extended label’s name does not affect the text that you save for a simulation object, changing its index could affect existing scenarios. Therefore, use caution in doing so.

              To change an extended label’s index:

              1. Choose Settings Application. The Application Settings dialog box opens.

              2. Select the Session Options page (Figure 18-14).

              3. Click the up or down arrow next to a label’s index number. The index number changes and, if applicable, the label moves up or down in the list.


            3. Deleting an Extended Label

              Deleting an extended label affects all scenarios that use that label. (In other words, it is not a scenario-specific setting.) If you delete an extended label, it is immediately removed from all simulation objects that are using that label.

              To delete an extended label:

              1. Choose Settings Application. The Application Settings dialog box opens.

              2. Select the Session Options page (Figure 18-14).

              3. In the Extended Labels window, select the label you want to delete.

                image

              4. Click the Delete button ( ).


          1. Simulation Object Icons

            The 2D Icons model set uses MIL-STD 2525B icons. Figure 18-16 illustrates basic icon shapes for friendly forces.


            image image image image image image


            Tracked Dismounted infantry Fixed-wing Rotary-wing Surface Subsurface


            Figure 18-16. MILSTD-2525B icons

            The color and shape code for 2D simulation object icons is:

            • Light blue – friendly.

            • Salmon – hostile.

            • Light green – neutral.

              Symbols have a black border except as follows:

            • If there is no border on the top, the entity domain is subsurface, for example, submarines.

            • Selected simulation objects have a white border.

        Symbols that represent units have unit identifiers above the symbol, as illustrated in Figure 18-17.


        image

        image Circle with slash = Team or crew One dot = Squad

        image

        Two dots = Section

        image

        Three dots = Platoon or Detachment image One bar = Company

        Figure 18-17. Unit echelon indicators

        Viewing Information about Objects — Simulation Object Icons

        image

            1. Changing the Size of 2D Icons

              The Plan View observer mode uses the 2D Icons model set for simulation objects. You can change the size of 2D icons. When many simulation objects are close together, reducing the size of the icons can reduce overlap.

              To change the size of simulation object icons:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Entity Display Settings page (Figure 18-18).


                image

                Figure 18-18. Entity Display Settings page

              3. Adjust the Simulation Object Icon Scale slider.

                You can also change the size of 2D icons from the Display Settings Toolbar.

                To change the size of simulation object icons from the Display Settings toolbar:

                1. On the Display Settings Toolbar, click the Icon Scaling button image). The Simula- tion Object Icon Scale Factor slider opens.

                2. Adjust the slider to change the size of the icons.


                image

                i

                i

                The Simulation Object Icon Scale Factor slider is a dockable widget that you can undock and leave visible as long as icon scaling is enabled.


                image


            2. Rotating 2D Icons to a Simulation Object’s Heading

              By default, when a simulation object’s heading changes, the heading indicator points to the new heading, but the icon remains oriented towards zero degrees (North). You can specify that icons rotate to the heading of the simulation object.



              image image

              Figure 18-19. 2D icon rotated to heading

              To rotate icons to a simulation object’s heading:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Entity Display Settings page (Figure 18-18).

              3. Select the Rotate Entity Military Standard Symbols to Heading check box.

        Viewing Information about Objects — Displaying HAT Lines for Entities (3D Only)

        image

          1. Displaying HAT Lines for Entities (3D Only)

            Height-above-terrain (HAT) lines are vertical lines that run from an entity to the ground and display the altitude of the entity (using whatever units are configured on the Display Units Settings page) (Figure 18-20). They help you understand the rela- tionship of the entity to the terrain.

            HAT lines are shown only for entities that could be above or below the ground, such as fixed and rotary-wing vehicles. You can show and hide these lines globally and you can specify that they be shown only for the selected entities.

            When you create or edit an entity, VR-Forces displays HAT lines even if they are other- wise disabled.



            image

            Figure 18-20. Entity height-above-terrain lines


            image

            ! Displaying height above terrain lines can reduce the frame rate.

            image

            To show or hide height-above-terrain lines:

            1. Choose Settings Display. The Display Settings dialog box opens.

            2. Select the Entity Display Settings page (Figure 18-10).

            3. To display lines, select the Enable Height Above Terrain Lines check box.

            4. To display lines only for selected entities, select the Only Display Height Above Terrain Lines For Selected Entities check box.


              image

              i

              i

              You can also enable and disable entity HAT lines by choosing Settings Entity Height Above Terrain Lines or by clicking the Entity Height Above Terrain Lines button image) on the Display Settings Toolbar.


              image


          2. Displaying Threat and Sensor Range Rings

        You can display a simulation object’s threat range – the area within which its armaments are effective. The threat range is displayed as a circle, with a line indicating the arma- ment and its direction of fire (Figure 18-21). A ring is displayed for each weapon system that the entity has. For example, in Figure 18-21, the M1A2 entity has an inner ring for its 62mm machine gun and an outer ring for its 120mm main gun.

        You can also display range rings for a simulation object’s sensors (Figure 18-22).


        image

        2D 3D

        Figure 18-21. Range rings (entity-level scenario)

        Simulation objects in aggregate-level scenarios display range rings that show their combat effectiveness and a footprint that represents the physical area that the unit occu- pies (Figure 18-22). Unit range rings have breaks to show the front, rear, left flank, and right flank sectors.



        image

        Footprint (green) Weapon (red) Sensor (blue)



        Figure 18-22. Range rings (aggregate-level scenario)

        You enable range rings globally. They are an observer-specific option. You display range rings on a per-entity basis. You can globally configure the color of rings, their transpar- ency, and the display of labels. In 3D views, you can specify whether or not to display a range sphere (Figure 18-23).


        image

        Figure 18-23. Range ring sphere


        image

        i

        i

        On small databases, a simulation object’s range ring may extend beyond the edge of the terrain display.


        image


            1. Enabling and Disabling the Display of Range Rings

              To enable or disable the display of range rings:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Observer Settings page (Figure 19-9).

              3. In the list of options, select or clear the Range Rings check box.


                image

                image

                i

                i

                You can also enable and disable range rings by choosing Observer Range Rings or by clicking the Range Rings button ( ) on the Observer Settings Toolbar.


                image


            2. Pinning Range Rings for a Simulation Object

              You display range rings on a per-entity basis. By default, if range rings are enabled, when you select an object, its range rings are displayed as long as the object is selected. You can pin range rings to an object so that they are displayed even if the object is not selected.

              To pin range rings for a simulation object:

              1. Enable range rings, as described in “Enabling and Disabling the Display of Range Rings,” on page 18-26.

              2. Select a simulation object.

              3. Choose Objects Pin Range Rings.


            3. Configuring the Display of Range Rings

              You can configure the color of range rings and their transparency by weapon type and sensor type. You can also configure the display of range ring labels (Figure 18-24). A label can display the entity name, weapon type, and range of the weapon.


              image

              Figure 18-24. Range ring labels

              To configure the display of range rings:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Range Rings Settings tab (Figure 18-25).

              3. To display a sphere in 3D views, select the Show Range Sphere in 3D Using Opacity Modifier check box. Optionally, change the opacity modifier value.

              4. To display the type of sensor or weapon system, select the Show Weapon Name check box.

              5. To display the name of the simulation object, select the Show Entity Name check box.

              6. To show the range of the sensor or weapon system, select the Show Range Value check box.

              7. To automatically display range rings when a simulation object is created or discov- ered on the network, select Display Range Rings by Default.


                image

                i

                i

                If this setting is selected, when you load a scenario, range rings are displayed for all simulation objects.


                image


              8. To display range rings for a selected simulation object that has not enabled range rings, select Display Range Rings for Selected.



                image

                Figure 18-25. Range Rings Settings page (AggregateLevel.sms)

              9. To always show the footprint of a simulation object, select Always Display Foot- print.

              10. To enable or disable display of range rings for a particular weapon system, select or clear the check box for that system.

              11. To change the color used to display a range ring:

                1. For the type of weapon system or sensor whose color you want to change, select User-Defined Color in the Color column list. The color swatch next to the list changes.

                2. Click the color swatch. A color picker dialog box opens.

                3. Select the color you want to use.

                4. Click OK.

              12. To change the opacity for a range ring, for the weapon system whose range ring opacity you want to change, change the value in the Opacity column.

        Viewing Information about Objects — Displaying Entity Resources

        image

          1. Displaying Entity Resources

            VR-Forces tracks the amount of resources that a simulation object has. You can view the status of resources in the Information dialog box.


            1. Viewing Numerical Resource Data

              The Information dialog box lists the simulation object’s current amount of resources, its starting amount, and the percentage remaining (Figure 18-26).


              image

              Figure 18-26. Resource Information page

              To view a simulation object’s resource status, on the Information dialog box, select the Resources page.

              Viewing Information about Objects — Displaying Bounding Volumes

              image

          2. Displaying Bounding Volumes

            You can display bounding volumes for simulation objects. Bounding volumes show the area around a simulation object that the back-end uses for intersection calculations.

            Bounding volumes are shown as translucent volumes in 3D and translucent rectangles in 2D (Figure 18-27). For simulation objects in aggregate-level scenarios, the bounding volume is equivalent to the footprint.


            image


            2D 3D


            image

            Aggregate-level bounding volumes


            Figure 18-27. Bounding volumes

            To enable or disable bounding volumes:

            1. Choose Settings Display. The Display Settings dialog box opens.

            2. Select the Observer Settings page (Figure 19-9).

            3. Select the observer mode for which you want to enable or disable bounding volumes.

            4. Select or clear the Bounding Volume check box.


            1. Showing Bounding Volumes Only for Selected Simulation Objects

              You can configure VR-Forces so that it shows bounding volumes only for selected simu- lation objects.

              To display bounding volumes only for selected simulation objects:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Observer Settings page (Figure 18-18).

              3. Select the observer mode for which you want to enable bounding volumes.

              4. Select the Bounding Volume check box.

              5. Select the Entity Display Settings page (Figure 18-10).

              6. Select the Show Bounding Volumes for Selected Entities check box.


        18.9. Configuring Object Console Messages

        The Information dialog boxes for simulation objects and tactical graphics have a console that displays messages sent from the simulation engine, from a simulation object’s plan, from other simulation objects, and from scripts. You can set the notifica- tion level that controls the display of these messages. You can save them to the clip- board, and you can clear the display. These messages are also sent to the Object Console Summary Panel.

        Scripted tasks can ask questions. You can answer these questions from the Object Console Summary Panel.


            1. Setting the Notification Level for Console Messages

              Console messages are displayed only if they match or exceed the notification level set for that object. The notification level is set individually for each object. You can set the notification level in the object’s Information dialog box, with the Notify Level set data request (for simulation objects), or with the objectConsoleNotifyLevel parameter in vrfSim.mtl. (For the set data request procedure, please see “Notify Level,” on

              page 34-28.)

              To set the notification level for an object’s console in the Information dialog box:

              1. Select the simulation object.

              2. Choose Objects Information. The Information dialog box opens.

              3. Expand the Object Console section (Figure 18-28).


                image

                Figure 18-28. Information dialog box, Object Console

              4. Select a notification level from the Notify Level list.


            2. Viewing All Console Messages

              You can view all object console messages in one place – the Object Console Summary Panel. Messages are displayed based on the notification levels of the individual simula- tion objects in the scenario. You can set the notification level in a simulation object’s Information dialog box or using the Notify Level set data request.

              When VR-Forces sends a message to a simulation object’s console, it displays an excla- mation point next to the entity until you view the message (unless you disable this feature). The messages in the Object Console Summary Panel also display an exclama- tion point until you open the Information dialog box for that entity or click Acknowl- edge All.


              image

              Figure 18-29. Object Console Summary Panel

              To display the Object Console Summary panel, choose View Object Console Summary Panel.

              To remove the exclamation point from messages in the Object Console Summary Panel, click Acknowledge All.


            3. Answering Questions from Scripted Tasks

              Scripted tasks can send questions to the object console. Questions are indicated by a question mark next to the message (Figure 18-30). The script will offer a set of responses as buttons, option buttons, or a list. You can answer questions from the Object Console and the Object Console Summary Panel.



              image

              Figure 18-30. Question in console

              To answer a question from a scripted task:

              1. On the Object Console or Object Console Summary Panel, click Answer Ques- tions. A dialog box with the possible answers is displayed.

              2. Choose an option.

              3. Click OK.


            4. Saving Console Messages

              If you want to save the messages that are sent to the console, you can copy them to the clipboard and then paste them into a file.

              To save console messages to the clipboard:

              1. Select the simulation object.

              2. Choose Objects Information. The Information dialog box opens (Figure 18-28).

              3. If the Object Console is collapsed, expand it.

              4. To save all messages in the console, click Copy to Clipboard. To save specific messages, select them and click Copy to Clipboard.

              5. Paste the text into the text editor or word processor of your choice.


            5. Displaying an Object Console Warning Icon

              VR-Forces can display a notification icon when an object receives a message on its object console (Figure 18-31). This option is enabled by default, however the default notification level is Warn and objects do not typically get messages at this level. The more likely use for this icon is to set the notification level to Info or lower and then check the console when a notification is received. For details about how to set the noti- fication level, please see “Setting the Notification Level for Console Messages,” on page 18-32.


              image

              Figure 18-31. Object console warning icon

              The icon is not displayed if the Information dialog box is open. If an icon is displayed for an object, when you open its Information dialog box, the icon is removed.

              To enable or disable the console warning icon:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Entity Display Settings page (Figure 18-10).

              3. Select or clear the Show Object Console Warning Icon check box.


            6. Clearing the Object Console

        To clear the messages from the object console, click Clear.

        Viewing Information about Objects — Viewing Object Counts

        image

        18.10. Viewing Object Counts

        You can display the number of live and destroyed simulation objects in the simulation you are viewing and the number of control objects, by type.

        To display the object counts, choose View Objects Count Panel. The Objects Count Panel is added to the display (Figure 18-32).


        image

        Figure 18-32. Objects Count Panel


        image 19. Creating Simulation Objects


        This chapter explains how to create and manipulate simulation objects in general, and entities in particular. For information about working with units, please see Chapter 24, Creating and Controlling Units.

        Creating Simulation Objects 19-3

        Default Placement of New Entities 19-3

        Placing Entities Inside Buildings 19-4

        Placing Simulation Objects on Other Simulation Objects 19-4

        Simulation Object Resources 19-4

        Deleting Simulation Objects 19-5

        Editing Simulation Objects 19-5

        Embarking and Disembarking Simulation Objects 19-7

        Embarking and Disembarking Simulation Objects Instantly 19-8

        Disembarking Simulation Objects Using the Disembark Command.. 19-11 Embedded Entities 19-12

        Configuring an Entity to Support Embedded Entities 19-13

        Assigning Tasks and Plans to Embedded Entities 19-15

        Restoring an Entity that has Embedded Entities 19-15

        Collision, Obstacle, and Feature Avoidance 19-16

        Entity Movement and Soil Type 19-17

        Using a Joystick to Control Entities 19-18

        Switching Between Systems 19-19

        Disabling Joystick Control 19-20

        Using the Keyboard to Control an Entity 19-20

        Using Ground Clamping 19-20

        Configuring Ground Clamping 19-22

        image

        Creating Simulation Objects

        Exaggerating the Scale of 3D Entity Models 19-23

        Hiding 3D Models 19-26

        Changing Force Colors 19-26

        Creating Simulation Objects — Creating Simulation Objects

        image

          1. Creating Simulation Objects

            The basic procedure for creating a simulation object is fairly simple:

            1. On the Create menu or Simulation Objects Palette, select the simulation object that you want to create.

            2. Click on the terrain to place the simulation object.

            3. Optionally, specify the properties of the simulation object, such as name, altitude, and heading.

        The generic procedures for choosing the simulation object to create, placing it on the terrain, and setting properties are described in Chapter 16, Creating and Placing Objects. This section provides additional details about simulation object creation and place- ment.

        You can also create simulation objects by copying existing simulation objects. For details, please see “Copying and Pasting Objects,” on page 16-21.

        You can create preconfigured units the same way you create individual entities. You can also create units by aggregating simulation objects. To learn how to create a unit, please see “Creating Units,” on page 24-2.


        image

        !

        !

        When you create simulation objects, if spot reports are enabled and a particular force is hidden, if you create a simulation object of the hidden force, you will not be able to see it. It is recommended that you disable spot reports or set the viewpoint to show all forces when you are creating scenarios. For details about spot reports, please see “Displaying Simulation Objects Based on Spot Reports,” on page 9-2.


        image


            1. Default Placement of New Entities

              By default, ground, lifeform, rotary-wing, and fixed-wing entities get placed on the ground. Surface and subsurface entities are created at sea level.

              Ground-based entities are placed at the highest possible terrain intersection at the loca- tion. If a terrain supports buildings with multiple levels, the entity is placed at the highest level. Once the entity begins moving, if the next calculated location resides in- between two levels of terrain, and if the entity is configured to respect terrain intersec- tions when moving, and there is no terrain blocking its movement, the entity places itself at the closest elevation to the desired location.

              Creating Simulation Objects — Creating Simulation Objects

              image

            2. Placing Entities Inside Buildings

              One of the benefits of creating entities in a 3D observer mode is the ease of placing them in the precise location and orientation that you want them to be in, particularly inside buildings. However, placing entities inside small enclosed spaces can be hindered by the location of walls relative to the observer. You can work around this problem by:

            3. Placing Simulation Objects on Other Simulation Objects

              If you want to place a simulation object on or in another simulation object, such as an aircraft on an aircraft carrier or a dismounted infantry entity in a truck, then you must embark the simulation object. Creating a simulation object on top of another simula- tion object will not provide the results you want. For example, if you create a fixed-wing entity and manipulate its location and altitude so that it looks like it is on the deck of an aircraft carrier, as soon as you start the simulation, the jet will start flying at that alti- tude, because it is not attached to the carrier. It is just created at a particular location. For complete details about embarking simulation objects, please see “Embarking and Disembarking Simulation Objects,” on page 19-7.


            4. Simulation Object Resources

              When you create a simulation object, it has a full complement of resources, as defined in the object parameter database. You do not have to assign resources to a simulation object when you create it. However, if you want a simulation object to start a simula- tion with less than a full set of resources, you can use the Resource set data request to set its resources at some amount less than 100%.

              Creating Simulation Objects — Editing Simulation Objects

              image

            5. Deleting Simulation Objects

        To delete a simulation object:

        1. Select the object you want to delete.

        2. Choose Objects Delete or press the Delete key.


        image

        i If you delete a unit, all its subordinates also get deleted.

        • If you delete a simulation object that has an intervisibility object pinned

        to it, the intervisibility object also gets deleted. For details, please see “Deleting Intervisibility Objects,” on page 46-12.


        image


          1. Editing Simulation Objects

            You can edit the following simulation object properties:

          2. Embarking and Disembarking Simulation Objects

        Embarkation places simulation objects into or onto other simulation objects, for example, dismounted infantry in a truck, trucks on an LCAC, or aircraft on an aircraft carrier. While embarked, the simulation objects travel with the simulation object on which they are embarked. Embarked simulation objects are not visible in the 2D view. They are always visible in the 3D view.

        Embarked entities can shoot while they are embarked if they are embarked on an entity that has object geometry enabled.


        image

        !

        !

        If you are using HLA and want to use the embarkation feature, you must use RPR FOM 2, draft 17 or later. VR-Forces includes configurations in the Simulation Connections Configuration dialog box that start VR-Forces using the correct FED file and FOM Mapper for RPR FOM 1.0 and RPR FOM 2.


        image


        You can attach control objects to simulation objects so that embarked simulation objects can use them to move about on the parent simulation object. For example, an aircraft could taxi towards a waypoint on the flight deck of an aircraft carrier.


        image

        i

        i

        Attached objects are shown in the Embarkation View on the Objects List Panel.


        image


        The embarkation status of simulation objects is displayed in the Embarkation View of the Objects List Panel (Figure 19-2).


        image

        Figure 19-2. Embarkation View

        You can embark and disembark simulation objects instantly (described in this section), or you can have them simulate embarkation and disembarkation using the Embark and Disembark tasks, described in Chapter 30, Embarkation, Wait, Radio, and Other Tasks.


        When you embark a simulation object using the Embark task, the simulation object can embark only on simulation objects that are configured to accept that type of simu- lation object. For example, LCACs are configured to accept several types of ground vehicles. You cannot give a DI an Embark task to embark on an LCAC. However, when you use the immediate embark method to embark a simulation object, you can use preconfigured slots (spaces) for simulation objects or specify an override. When you specify an override you can embark a simulation object on any other simulation object at the coordinates you enter. However, it is your responsibility to know what the proper coordinates are.


        image

        i

        i

        Embarked entities controlled by joystick cannot disembark. For example, if you use a joystick to control a fixed-wing taking off from a carrier, the aircraft will take off, but it will remain in an embarked state.


        image


            1. Embarking and Disembarking Simulation Objects Instantly

              You can embark and disembark simulation objects instantly in the following ways:

            2. Disembarking Simulation Objects Using the Disembark Command

        Like the Embark On command, the Disembark command is typically used as part of scenario development. To simulate disembarkation, you would use the Disembark task. To provide instant disembarkation in a plan, you would use the Disembarked set data request.


        image

        i

        i

        Embarked entities controlled by joystick cannot disembark. For example, if you use a joystick to control a fixed-wing taking off from a carrier, the aircraft will take off, but it will remain in an embarked state.


        image


        To disembark a simulation object instantly:

        1. Select the simulation object that you want to disembark.

        2. Choose Objects Disembark. If the simulation object was embarked using the default embarkation point, it is disembarked next to the former parent simulation object. If the simulation object was embarked using a position override, it is disem- barked in the same location as the former parent.

        To disembark a simulation object in the Embarkation View:

        1. Open the Embarkation View.

        2. Drag the simulation object you want to disembark from the parent simulation object to the force level.


        Disembarking All Simulation Objects

        When you disembark all simulation objects from a parent, the placement of the simula- tion objects depends on how they were embarked. If the simulation objects were embarked with the Embark On command or the Embark task, they are disembarked to separate locations near the parent. If they were embarked with the Embarked set data request, they are all disembarked in the same location in the center of the parent simu- lation object. Since this behavior is usually not desirable, you should understand how you embarked the simulation objects before you use this command.

        To disembark all simulation objects from a parent entity:

        1. Select the parent simulation object.

        2. Choose Objects Disembark All.


          1. Embedded Entities

            Embedded entities are a convenient way to manage entities that are typically embarked on other entities.

            Ships, planes, and vehicles often carry other platforms or personnel. You can simulate this relationship by embarking entities on other entities. However, this involves creating the embarking entities, giving them plans, embarking them, disembarking them, and otherwise managing the relationship. This can be inconvenient if you need to simulate large numbers of embarked entities, such as the airplanes and helicopters on an aircraft carrier or multiple personnel on a personnel carrier.

            The embedded entity feature lets you configure entities with a set of embedded entities. You can then deploy the embedded entities and give them tasks or plans. Once deployed, there is no difference between an embedded entity and any other entity, except that a parent entity can recover a deployed entity. You do not need to manage the initial process of creating the relationship between the entities via embarkation and disembarkation.

            For details about deploying and recovering embedded entities, please see “Embedded Entity Tasks,” on page 30-14.


            1. Configuring an Entity to Support Embedded Entities

              Embedded entities are configured in systems, which you then add to an entity in the Simulation Object Editor. An entity can have only one embedded entity system. There- fore, if you need different configurations of embedded entities for different parent enti- ties, you must create a system for each configuration.

              Within a configuration, you must specify each embedded entity. In other words, you cannot specify a system as containing, for example, 5 helicopters and 40 F/A-18 jets. In this case the system would have to individually specify each helicopter and each jet.

              A system definition file for embedded entities specifies the entities and the metadata needed to edit properties in the Simulation Object Editor. You must give each entity a unique name.

              An entity is formatted as follows (from ./data/simulationModelSets/EntityLevel/vrfSim/ systems/other/ddg-embedded-support-craft.sysdef):

              (embedded-entities (ee-1

              (entity-name "SH-60 Seahawk Alpha") (entity-type 1 (1 2 225 22 3 1 0))

              (deployment-time 0.0)

              (recovery-distance 35.0)

              (relative-position $rel-pos-lamps-a) (relative-heading $rel-heading-lamps-a)

              )

              ...

              (ee-2

              (entity-name "RHIB Alpha")

              (entity-type 1 (1 3 225 63 8 0 0))

              (deployment-time 15)

              (recovery-distance 50.0)

              (relative-position $rel-pos-rhib-a) (relative-heading $rel-heading-rhib-a)

              )

              ...

              )


              The relative-position and relative-heading parameters are variables that link to the meta- data, as follows:

              (parameter-data-list (vector-parameter-data

              (parameter-name "rel-pos-lamps-a") (variable-type "DtRwVector")

              (display-label "Seahawk Alpha's relative position") (display-units "meters")

              (source-units "meters")

              (default-value -75.000000 0.000000 -6.500000)

              (relative-to "")

              )

              (vector-parameter-data

              (parameter-name "rel-pos-rhib-a") (variable-type "DtRwVector")

              (display-label "Rigid-hull Alpha’s relative position") (display-units "meters")

              (source-units "meters")

              (default-value -75.000000 10.000000 -6.500000)

              (relative-to "")

              )

              ...

              (real-parameter-data

              (parameter-name "rel-heading-lamps-a") (variable-type "DtRwReal")

              (display-label "Seahawk Alpha's relative heading") (display-units "degrees")

              (source-units "degrees") (default-value 0.000000)

              )

              (real-parameter-data

              (parameter-name "rel-heading-rhib-a") (variable-type "DtRwReal")

              (display-label "Rigid-hull Alpha’s relative heading") (display-units "degrees")

              (source-units "degrees") (default-value 90.000000)

              )

              ...

              )

              Figure 19-4 illustrates the properties dialog box created for the system shown in the previous paragraphs.



              image

              Figure 19-4. Embedded Entity Properties dialog box


            2. Assigning Tasks and Plans to Embedded Entities

              Once an embedded entity is deployed, it is just like any other entity in the scenario. You can give it independent tasks or write a plan for it. Follow the standard procedures for these activities.


            3. Restoring an Entity that has Embedded Entities

              If you deploy an embedded entity and it gets destroyed, it is removed from the scenario and is not available to be deployed again. However, if you restore a parent entity and it had deployed entities that were subsequently destroyed, it is restored to the full comple- ment of embedded entities. Entities that are deployed at the time the parent is restored are not affected. They are not duplicated in the parent’s inventory and their relationship is not affected.

              Creating Simulation Objects — Collision, Obstacle, and Feature Avoidance

              image

              image

          2. Collision, Obstacle, and Feature Avoidance

            By default, in entity-level scenarios, simulation objects avoid other simulation objects, features, and obstacle control objects. If, while carrying out a task, a ground, lifeform, or rotary-wing entity detects that it is on course to collide with another entity, a feature, or an obstacle, it alters its route to avoid the collision. Then it returns to its task.


            image

            i

            i

            • In entity-level scenarios, aggregated units do not avoid obstacles and collisions. When disaggregated units move, the individual members of the units use collision avoidance.

            • In aggregate-level scenarios, there is no collision avoidance between simulation objects. If a unit encounters an obstacle, it stops, sends a message to the console, and awaits further instructions.


            image


            When an entity avoids an obstacle, it does not necessarily follow the outline of the obstacle, it avoids the obstacle's bounding volume, which is conceptually the smallest rectangle that bounds all of the points in the obstacle.

            Ground entities avoid features, such as buildings and plants. By default, entities avoid other entities (some cultural features are created as entities), buildings, water, and vege- tation. (LCACs do not avoid vegetation by default.)

            Collision avoidance has the following qualifications:

            • To specify that ground entities should not move through the terrain (for example, through a wall or through a hill), set the check-terrain-collisions parameter in the automotive actuator component (powertrain) to True. For performance reasons, it defaults to False, so that entities that do not care about terrain collisions do not perform the check.

            • If an entity is tasked to move to a point that is inside an obstruction, or very close to one, it might never reach the point, but it will continue to try to reach the point as long as the task is in effect. This behavior also applies to entities following routes that have vertices inside an obstruction.

            • If a terrain has geometric features as well as point vector features, the feature avoid- ance may not work because the points are placed on the terrain on “top” of the existing geometry, which means they are on top of the geometric feature.

            • Do not place entities inside obstacles. Their behavior will be unpredictable.

            • Although you can assign a force to an obstacle when you create it, it has no effect on entity behavior. Entities avoid all obstacles.

            You can configure the objects that an entity will avoid by editing its entry in the object parameter database. For details about configuring obstacle avoidance, please see “Configuring Obstruction Avoidance,” on page 73-4.

            Creating Simulation Objects — Entity Movement and Soil Type

            image

          3. Entity Movement and Soil Type

            In VR-Forces, the movement of simulation objects is affected by the surfaces on which they are moving. The speed of movement over a given surface (as a percentage of ordered speed) is configured in the soil-list block in a simulation object’s object param- eter database entry.

            Table 19-1 lists the soil types supported for terrain databases and how they map to the roughness types that can configured in the soil-list block for VR-Forces simulation objects.

            image

            Table 19-1: Soil type/roughness type mappings


            Soil type Roughness type

            Soil type Roughness type

            ocean deep-water

            deepLake deep-water

            shallowLake shallow-water

            deepRiver deep-water

            shallowRiver shallow-water

            shallowPond shallow-water shallowStream shallow-water dryGround hard-packed

            pavedRoad paved-road

            gravelRoad gravel

            dirtRoad gravel

            asphalt hard-packed

            USRailroad hard-packed

            softSoil sand

            swamp muck

            mud muck

            forest hard-packed

            grass hard-packed cultivatedFields hard-packed orchards hard-packed

            rock rocks

            boulder rocks

            sand sand

            building hard-packed

            tree hard-packed

            image

            Creating Simulation Objects — Using a Joystick to Control Entities

            image

            image

          4. Using a Joystick to Control Entities

        VR-Forces supports use of joysticks, other types of game controllers, and keyboard keys to control ground, fixed-wing, and rotary-wing entities. You can attach multiple joysticks, which allows you to control multiple entities, movement and weapons fire on one entity, or some combination. You can also use a joystick and keyboard mappings together to control an entity.

        Joystick control is managed in the front-end. Joysticks should be attached to the computer from which you are running the front-end. Control messages are sent to the back-end, which can be on any computer in the simulation.


        image

        i

        i

        • Red Hat 6 does not support joysticks by default, but it can be enabled in the operating system. For details, go to this web site: https://access.redhat.com/solutions/64114

        • You cannot enable or disable joystick support for all entities at once. You can only enable joysticks for individual entities.

        • Embarked entities controlled by joystick cannot disembark. For example, if you use a joystick to control a fixed-wing taking off from a carrier, the aircraft will take off, but it will remain in an embarked state.

        • For information about how to configure joysticks, please see “Config- uring Joysticks and Keyboard Control,” on page 75-2.


        image


        To enable joystick control:

        1. Select the entity for which you want to enable joysticks.

        2. Choose Objects Take Control. The Take Control dialog box opens.


          image

          Figure 19-5. Take Control dialog box

        3. Select a joystick configuration from the Configuration list. (If you have specified a joystick configuration as a favorite, you do not have a choice of the configuration to use.)

        4. Select the entity functions you want to control, usually movement and one or more weapons. (You can have more than one joystick attached and can also use keyboard controls, if they are configured.)

        5. Click OK.

        Creating Simulation Objects — Using a Joystick to Control Entities

        image

            1. Switching Between Systems

              Systems that are controlled by joysticks can be organized into functional groups so that you can configure them similarly and switch between the systems using a “switch between” key or button. VR-Forces includes a switch group for weapons. If an entity has multiple weapon systems, you can manage them in the following ways:

            2. Disabling Joystick Control

        To disable joystick control:

        1. Select the entity for which you want to disable joysticks.

        2. Choose Objects Release Control.


        image

          1. Using the Keyboard to Control an Entity

            The joystick configuration process allows you to configure keyboard control of entity movement and weapons. You can use keyboard control along with joysticks. For example, you could control entity movement from the keyboard and weapons from a joystick, or the opposite.

            To enable or disable keyboard control, follow the procedures for enabling and disabling joystick control. Similarly, to configure keyboard control, follow the joystick configura- tion process. For more information, please see “Using a Joystick to Control Entities,” on page 19-18 and “Configuring Joysticks and Keyboard Control,” on page 75-2.


          2. Using Ground Clamping

            Because of differences in terrain databases among exercise participants, entities can sometimes appear to be underground or hovering above the terrain surface. To compensate, VR-Forces can clamp land and sea entities to the terrain surface. When ground clamping is enabled, VR-Forces keeps an entity anchored to the terrain surface regardless of the altitude data contained in its state update.


            image

            i

            i

            • Use of ground clamping can reduce your frame rate. If you correlate the simulation and visualization terrain databases, you can eliminate the need to use ground clamping.

            • Although ground clamping controls are available in aggregate-level scenarios, since aggregate-level scenarios do not use 3D models, they are not useful.


        image

        Creating Simulation Objects — Using Ground Clamping

        image


        To enable or disable ground clamping:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Entity Display Settings page (Figure 19-6).


          image

          Figure 19-6. Ground clamping settings

        3. Select or clear the Enable Ground Clamping check box.


        image

        image

        i

        i

        You can also enable and disable ground clamping by choosing Settings Ground Clamping, or clicking the Ground Clamping button ( ) on the Display Settings Toolbar.


        image

        Creating Simulation Objects — Using Ground Clamping

        image

            1. Configuring Ground Clamping

              You can configure the following aspects of ground clamping:

              • Enable or disable ground clamping.

              • Enable or disable orientation clamping.

              • Force lifeforms to remain upright relative to the plane of their location when moving up slopes or steps, rather than being perpendicular to the terrain.

              • The distance from the terrain within which entities are clamped.

        To configure ground clamping:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Entity Display Settings page (Figure 19-6).

        3. To enable or disable a ground clamping option, select or clear its check box.

          image

        4. To specify the distance from the terrain in which entities are ground clamped, adjust the Ground Clamping Cutoff Distance Scale slider or type a value, in meters, in the box. You can also access the Ground Clamping Cutoff Distance Scale slider by clicking the down arrow next to the Ground Clamping button ( ) on the Display Settings Toolbar.


        image

        i

        i

        The setting for the Ground Clamping Cutoff Distance Scale maximizes at 100 meters. If you set it to the maximum, the distance is infinite and all entities are ground-clamped.


        image


          1. Exaggerating the Scale of 3D Entity Models

            If you view the terrain in Stealth observer mode, beyond a certain distance most 3D entity models are too small to see. Model scaling lets you exaggerate the scale of entity models to see them at a great distance. Figure 19-7 shows the same scene with model scaling off and on. When model scaling is off, only the largest entities are visible. When models are scaled, they are all visible.

            VR-Forces supports the following types of model scaling:

            • XR scaling. XR scaling tries to give all entities approximately equal visibility. It does not preserve size relationships between entities. The visual effect of model scaling depends on an entity’s size and the observer’s distance from the entity. When the observer is close to an entity, scaling models may not make any noticeable differ- ence in its size.

            • Linear scaling. Linear scaling scales all entities by the current model scale factor. The distance from the observer is not taken into account. A model scale factor of 10 scales all entities to be 10 times normal size.



              image

              Figure 19-7. Model scaling off and on (Stealth observer mode)

              Creating Simulation Objects — Exaggerating the Scale of 3D Entity Models

              image


              Another way to quickly change the visibility of entities is to switch to XR observer mode. In XR mode, entities are immediately scaled and are represented by colorized 3D models to enhance their visibility.


              image

              Figure 19-8. XR mode


              To scale entity models:

              1. Choose Observer Advanced Settings. The Display Settings dialog box opens to the Observer Settings page (Figure 19-9).


                image

                Figure 19-9. Observer Settings page

              2. In the list of observer attributes, select Model Scaling.

              3. In the Model Scaling Type list, select the type of scaling you want to use – XR or linear.

              4. Optionally, change the Maximum Scale Factor.

              5. Adjust the Scale Factor slider to the amount of scaling that you want.

              Creating Simulation Objects — Hiding 3D Models

              image

          2. Hiding 3D Models

            You can hide 3D models and 3D colorized models.

            To hide 3D models:

            1. Choose Settings Display. The Display Settings dialog box opens.

            2. Select the Observer Settings page (Figure 19-9).

            3. In the list of observer settings, clear the Main Model check box.


          3. Changing Force Colors

        By default, labels, detonation lines, and other force-related simulation object graphics (including the 3D Colorized Model model set) are displayed using primary colors (red, blue, and green). You can change the force coloring to use MIL-STD 2525B colors (light blue, light green, and salmon).

        You can also change the color of a force in the Simulation Object Editor. For details, please see “Editing a Force,” on page 64-23.

        To change force coloring:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Entity Display Settings page (Figure 19-6).

        3. Select the Force Coloring Settings option that you want.


        image

        20. Generating Traffic (Pattern of Life)


        This chapter explains how to automatically generate pattern of life simulation object traffic and how to create and task pedestrian crowds.

        Generating Traffic 20-2

        Creating Spawn Points 20-2

        Creating Sink Points 20-4

        Spawn Patterns 20-5

        How Spawn Events are Scheduled 20-6

        Spawning Entities in Bursts 20-8

        Using a Custom Plan 20-9

        Default Spawn Patterns and Scenario-Specific Patterns 20-9

        Creating a Spawn Pattern 20-10

        Copying a Spawn Pattern 20-14

        Editing a Spawn Pattern 20-15

        Deleting a Spawn Pattern 20-16

        Generating Traffic (Pattern of Life) — Generating Traffic

        image

          1. Generating Traffic

            The VR-Forces traffic feature (also called spawn and sink or pattern of life) lets you automatically generate background traffic for your scenario.

            image

            Automatically generated (spawned) simulation objects are created at spawn points. The default behavior for a spawned simulation object is to randomly choose a destination, called a sink point, and move towards that point. When it arrives at the sink point it is removed from the scenario. This creates the effect of

            purposeful activity in an area of the terrain without the need to create and task simula- tion objects individually.

            As an alternative to the default behavior, you can write a plan that is assigned to each simulation object created at a particular type of spawn point. This plan can include any tasks and set data requests that are appropriate for the object type.

            The behavior of a spawned simulation object, as well as other details such as how frequently they are spawned and how many spawned simulation objects can exist at one time, is configured in a “spawn pattern”. VR-Forces comes with two spawn patterns to get you started. You can edit spawn patterns and create as many new ones as you wish. Spawn points and sink points for new and edited spawn patterns are dynamically added to the Create menu and Tactical Graphics Palette so that it is easy to create new spawn and sink points for all of the available patterns.

            The SubwayPOL example scenario has spawn patterns that demonstrate continuous simulation object creation, burst traffic, and use of a custom plan. The release also includes video tutorials that show simple examples of spawn patterns.


            image

            i

            i

            Spawn and sink points are automatically added to the Create menu. However, they are not flagged as Favorites on the Tactical Graphics Palette. If you flag a spawn or sink point as a Favorite (by clicking the star next to the point’s name in the list of points) a duplicate entry is added to the Create menu.


            image


          2. Creating Spawn Points

            You can create spawn points from the Create menu, the Tactical Graphics Palette, or from the Spawn Pattern Manager. Figure 20-1 illustrates a spawn point.



            image

            Figure 20-1. Spawn point

            Generating Traffic (Pattern of Life) — Creating Spawn Points

            image


            If the plan for a spawn point specifies Use Roads and a spawn point is placed too far away from the road network to use roads, a message is sent to the spawn point’s console. If warning icons are enabled, a warning icon is displayed. For details about the Use Roads option, please see “Creating a Spawn Pattern,” on page 20-10. For details about configuring console messages and warning icons, please see “Configuring Object Console Messages,” on page 18-31.

            To create a spawn point from the Create menu:

            1. Choose Create Spawn Points type, where type is one of the spawn patterns. The cursor changes to the waypoint symbol.

            2. Click on the terrain where you want to place the spawn point. You can continue clicking to create additional spawn points.

            3. Right-click to exit create mode.

              To create a spawn point from the Spawn Pattern Manager:

              1. Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).


                image

                Figure 20-2. Spawn Pattern Manager

              2. Select the spawn pattern for which you want to create spawn points.

              3. Click Create Spawn Points. The cursor changes to the waypoint symbol.

              4. Click on the terrain where you want to place the spawn point. You can continue clicking to create additional spawn points.

              5. Right-click to exit create mode.

              Generating Traffic (Pattern of Life) — Creating Sink Points

              image

          3. Creating Sink Points

            If you are using the default spawned simulation object behavior – pick a sink point and move to it – then you have to create one or more sink points for the simulation objects to move to. Entities created at a given type of spawn point automatically choose among sink points of the same type. (You can configure spawned simulation objects to move to any kind of point by editing the spawn pattern. For details, please see “Creating a Spawn Pattern,” on page 20-10.) You can create sink points from the Create menu, the Tactical Graphics Palette, or from the Spawn Pattern Manager. Figure 20-3 illustrates a sink point.



            image

            Figure 20-3. Sink point

            If a sink point is more than 10 meters from a road and simulation objects move towards it with the Use Roads criteria, they move to the closest point on the road to the sink point and are then removed from the scenario.

            To create a sink point from the Create menu:

            1. Choose Create Sink Points type, where type is one of the spawn patterns. The cursor changes to the waypoint symbol.

            2. Click on the terrain where you want to place the sink point. You can continue clicking to create additional sink points.

            3. Right-click to exit create mode.

              To create a sink point from the Spawn Pattern Manager:

              1. Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).

              2. Select the spawn pattern for which you want to create sink points.

              3. Click Create Sink Points. The cursor changes to the waypoint symbol.

              4. Click on the terrain where you want to place the sink point. You can continue clicking to create additional sink points.

              5. Right-click to exit create mode.


          4. Spawn Patterns

        A spawn pattern configures the following aspects of spawned simulation object creation and behavior:

        When you use the default plan, the Create Spawn Pattern dialog box lists the sink points that this pattern will use.

        The SubwayPOL example scenario has spawn patterns that demonstrate spawning simulation objects continuously and in bursts. It also demonstrates use of a custom plan. The following sections describe these different ways to set up spawn patterns.


            1. How Spawn Events are Scheduled

              Spawn patterns control the time period during which simulation objects are spawned and the rate at which they are spawned during that time period. A spawn pattern can use one of the following options:

            2. Spawning Entities in Bursts

              image

              You can introduce additional variation to the spawn frequency by specifying that simulation objects be spawned in bursts. A burst pattern controls spawning behavior within a fixed period of time. For example, you could use a burst pattern to represent a cycle of train disembarkations or rush hour traffic.

              Burst patterns have the following parameters:

              • Burst Period. The period of time during which a burst can take place.

              • Burst Length. The percentage of the burst period in which to spawn simulation objects.

              • Offset Start Time. An offset from the start of the burst period at which to start spawning simulation objects.

                Within a burst, simulation objects are created at the rate determined by the spawn interval and spawn interval variance values.

                Figure 20-6 illustrates a series of bursts. The burst period is 10 minutes. The offset start time is two minutes, so each burst starts two minutes after the start of the burst period. The burst lasts for 40% of the length of the burst period, in this case four minutes.

                Within each burst, the frequency of spawn events is controlled by the spawn interval and variance values.



                image

                image

                image

                Burst Period = 10 minutes


                image


                Spawn event



                Offset Start Time = 2 minutes Burst Length = 40%


                Figure 20-6. Burst periods


            3. Using a Custom Plan

              image

              As noted in “Generating Traffic,” on page 20-2, the default behavior for a spawned simulation object is to choose a sink point, move to the sink point, and be removed from the scenario. However, you can introduce more complex

              behaviors for spawned simulation objects by writing a custom plan for a spawn pattern. By creating a custom plan, the simulation objects can engage in a complex set of behav- iors, but you still have the benefit of automatic generation. An example of using a custom plan would be to generate a steady stream of jets taxiing to a runway and taking off from an airport.

              Custom plans can include all of the tasks, sets, conditions, and global commands that a regular individual plan has. The plan is treated as an individual plan and applied to each simulation object as it is created. When you write a custom plan, simulation objects do not move to sink points. They remain in the scenario unless their plan removes them. You can delete simulation objects without needing to specify the specific simulation object with the Delete Self global command.


            4. Default Spawn Patterns and Scenario-Specific Patterns

        The VR-Forces includes default spawn patterns for civilian vehicles and civilian life- forms. When you create a scenario, these patterns are added to the scenario. When you save a scenario, the spawn patterns get saved with the scenario in the scenario extras file (.xtr). (This includes the default spawn patterns if you do not edit them, the edited versions if you have edited them, and any new spawn patterns you have created.) They are now scenario-specific. The next time you load the scenario, it uses the spawn patterns in the scenario extras file, not the default spawn patterns.

        If you want to have additional default spawn patterns for your scenarios, you can add entries to ./appData/settings/vrfSim/defaultSpawnTemplates.mtl. Copy one of the patterns in the file, then change the name and parameter values to suit your needs. Or, create a spawn pattern in a scenario and copy it from the .xtr file to defaultSpawnTemplates.mtl.


          1. Creating a Spawn Pattern

            Previous sections have explained the various components of a spawn pattern. This section explains how to create one.

            To create a spawn pattern:

            1. Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).

            2. Click New Pattern. The Create Spawn Pattern dialog box opens (Figure 20-7).


              image

              Figure 20-7. Create Spawn Pattern dialog box

            3. In the Name box, type a name for the spawn pattern. This name is used for the label for spawn points and sink points created from this pattern. This is a required field.

            4. In the Description box, type a description of the pattern. This description is listed in the Spawn Pattern Manager to help identify the purpose of the pattern. This is a required field.


            5. Specify the maximum number of simulation objects that can be spawned from a spawn point using this pattern and exist in the scenario at the same time. When the maximum is reached for a given spawn point, no more simulation objects are spawned from that point until an simulation object that was spawned from that point is removed from the scenario.

              For example, if the maximum number of simultaneous simulation objects for a spawn pattern is 200 and you have 10 spawn points of that type, you could have as many as 2000 spawned simulation objects. None of the spawn points will spawn more than 200 simulation objects at one time.


              image

              !

              !

              A high maximum number of simultaneous simulation objects along with a small spawn interval can quickly generate tens to hundreds of simulation objects. This may affect performance.


              image


            6. Specify the simulation object types to create:

              1. Click the Add button. The Entity Type dialog box opens. This dialog box lists simulation objects by category.

              2. Select the category for the simulation object type you want to add.

              3. Select the simulation object type that you want to add. The simulation object is added to the Type of Entity to Create list.

              4. Add additional simulation object types as desired.


                image

                i

                i

                The Entity Type dialog box lets you specify all types of simulation objects, cultural features, and control objects, some of which do not necessarily make any sense to spawn. It is up to you to select types of simulation objects that make sense.


                image


            7. Choose an option in the Spawn Timing group box, as follows:

              • Spawn Continuously. Entities are spawned throughout the simulation.

              • Spawn Based on Time of Day. Specify the starting time of day and ending time of day during which you want simulation objects to be spawned.

              • Spawn Based on Simulation Time. Specify the starting simulation time and ending simulation time during which you want simulation objects to be spawned.


            8. Optionally, select Spawn Entities in Periodic Bursts. (For an explanation of peri- odic bursts, please see “Spawning Entities in Bursts,” on page 20-8.) If selected, configure as follows:

            9. Specify the spawn interval. This specifies the amount of time between each spawn event, modified by the spawn interval variance.

            10. Specify the spawn interval variance as a percentage of the spawn interval.

            11. In the Spawn Behavior group box, select a behavior option as follows:

              – Use Custom Plan:

              1. Click Edit Plan. The Edit Custom Plan dialog box opens.


                image

                Figure 20-8. Edit Custom Plan dialog box

              2. Write a plan that each simulation object created from this spawn pattern will use. Unless you want the simulation objects to remain in the scenario perma- nently, end the plan with a Delete Self command. (For details about how to write plans, please see Chapter 36, Writing Plans.)


                – Use Default Plan:

                1. Optionally, select the Specify Speed check box and specify the minimum and maximum speeds for spawned simulation objects. If you do not select this option, spawned simulation objects move at the default ordered speed in their OPD file. If you select it, they move at randomly chosen speeds between the minimum and maximum values. This option introduces some variance in behavior. Although the GUI allows you to set any maximum speed, simulation objects will not move faster than the maximum speed in the OPD file.

                2. To have a simulation object move on roads, select the Use Roads check box. If this option is cleared, simulation objects move directly towards sink points without regard to vector road networks.


                  image


                  !

                  !

                  Use Roads is valid only for ground vehicles. Do not select this option for any other simulation object type.

                  If Use Roads is selected, spawn points must be within 10 meters of the road. If a spawn point is farther away, the simulation objects are removed from the scenario as soon as they are created.

                  If a sink point is more than 10 meters from a road, simulation objects that are moving towards that sink point move to the point on the road that is closest to it and are then removed from the scenario.


                  image


                3. Optionally, use the Add button to edit the Sink Points list. A new spawn pattern will not have any sink points listed because until you create the spawn pattern, you cannot create any sink points for that pattern. Entities will auto- matically use sink points that match the spawn pattern, so after you create them, you do not have to add them to the list. However, they can also move to waypoints. If you want spawned simulation objects to move to waypoints, you must add them to the list.

            12. Click Create.


            1. Copying a Spawn Pattern

              If you want to create a new spawn pattern that will be similar to an existing spawn pattern, you can copy the existing spawn pattern to a new name.

              To copy a spawn pattern:

              1. Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).

              2. Select the spawn pattern that you want to copy.

              3. Click Copy Pattern. The Create Spawn Pattern dialog box opens. It has a default name based on the original pattern name.

              4. Edit the spawn pattern. The meaning of each option is described in “Creating a Spawn Pattern,” on page 20-10.

              5. Click Create.

        Generating Traffic (Pattern of Life) — Editing a Spawn Pattern

        image

          1. Editing a Spawn Pattern

            You can change any of the parameters of a spawn pattern. The changes do not affect any simulation object that has already been spawned.

            To edit a spawn pattern:

            1. Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).

            2. Select the pattern that you want to edit.

            3. Click Edit Pattern. The Edit Spawn Pattern dialog box opens (Figure 20-9).


              image


              Figure 20-9. Edit Spawn Pattern dialog box

            4. Change any value as desired. The meaning of each option is described in “Creating a Spawn Pattern,” on page 20-10.

            5. Click Update.

              Generating Traffic (Pattern of Life) — Deleting a Spawn Pattern

              image

          2. Deleting a Spawn Pattern

            If you delete a spawn pattern, all spawn points of that type get deleted. Sink points do not get deleted. The spawn and sink points of this type are removed from the Create menu and Tactical Graphics Palette. If the scenario is running, any simulation objects that were spawned from these points continue executing their plans.

            To delete a spawn pattern:

            1. Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).

            2. Select the spawn pattern that you want to delete.

            3. Click Delete Pattern. You are prompted to confirm the deletion.

            4. Click Yes.


        image

        21. Crowds and Multiple Simulation Objects


        This chapter explains how to create many simulation objects at one time and how to create and task pedestrian crowds.

        Creating Multiple Simulation Objects and Crowds 21-2

        Creating Crowds Using a Pedestrian Area 21-2

        Adding Entities to a Pedestrian Area 21-3

        Creating Crowd Units 21-3

        Crowd Tasks 21-4

        Creating Multiple Simulation Objects 21-5

        Adding an Area for Multiple Simulation Object Creation 21-8

        Specifying the Simulation Objects to Create 21-8

        Pedestrian-Oriented Tactical Graphics 21-9

        Using Civilian Visit Points 21-10

        Crowds and Multiple Simulation Objects — Creating Multiple Simulation Objects and Crowds

        image

          1. Creating Multiple Simulation Objects and Crowds

            VR-Forces can quickly create multiple simulation objects within an area. This allows you to create crowds, traffic, or other multi-object groups without having to place each simulation object by hand. You can use any of the following methods to create multiple objects:

            • Pedestrian area. A pedestrian area gets populated by a random number of male and female civilians. They execute a wander task.

            • Multiple simulation objects. You can specify the number of simulation objects to create, the type of objects to create, and you can assign tasks and set data requests to them.

            • Crowd unit. Create a crowd unit from the Simulation Objects Palette or aggregate individual humans into a crowd unit. Assign crowd-specific tasks to the crowd.


              image

          2. Creating Crowds Using a Pedestrian Area

        When you create a pedestrian area, VR-Forces populates it with a random number of male and female civilian entities. They are created as a ground unit. They are all assigned a wander task. You cannot specify the number of entities to create or the mix of entities to create.


        image

        !

        !

        If you delete a pedestrian area, all of the entities that were created for it are also deleted.

        You can create pedestrian areas only in navigation areas.


        image


        To create a crowd using a pedestrian area:

        1. Open the Hazards/Obstacles Palette.

        2. Select Pedestrian Area.

        3. Draw an area on the terrain as you would any other areal tactical graphic. When the area is completed, VR-Forces creates entities to populate the area.

        Crowds and Multiple Simulation Objects — Creating Crowd Units

        image

            1. Adding Entities to a Pedestrian Area

              After you create a pedestrian area, you can automatically add additional entities to the area.

              To automatically add entities to a pedestrian area:

              1. Select the area.

              2. Choose Task Create Pedestrians. The Create Pedestrians dialog box opens.

              3. Specify the number of pedestrians to create.

              4. Select a placement option.

              5. Select or clear the Restrict To Area check box.

              6. Click OK. The pedestrians get added to the area.


        image

          1. Creating Crowd Units

            VR-Forces has three preconfigured crowd units: small, medium, and large. They create a unit of civilian males and females. You can also create crowd units by aggregating individual human entities. However, some of the animations used in crowd tasks are specific to the civilian characters used in the supplied units.

            When you place a crowd, if the terrain has pedestrian paths or other pedestrian-specific locations, the members of the crowd are placed in these locations.

            Crowd members get created within a configurable radius of the location you specify, with a configurable density. By default, crowds are created using the parameters in Table 21-1. You can change the values in the Simulation Object Editor.

            Table 21-1: Crowd units


            Unit

            Radius (m)

            Density

            Approximate Size*

            Civilian Crowd (Small)

            15

            2

            50

            Civilian Crowd (Medium)

            30

            2

            100

            Civilian Crowd (Large)

            50

            2

            175

            *If there are not enough valid locations to place entities, the size of the unit may be smaller than the theoretical maximum.

            image


            Crowd units are supported only in entity-level scenarios.


            image

            !

            !

            You can create preconfigured crowds only in navigation areas and crowd tasks can be executed only in navigation areas. Although you can aggregate individual entities into a crowd outside of a navigation area, they will not be able to execute any crowd tasks.


            image

            Crowds and Multiple Simulation Objects — Creating Crowd Units

            image


            To create a crowd:

            1. Click the Simulation Objects Palette.

            2. Select the Unit category.

            3. Select the Civilian Crowd (Small), Civilian Crowd (Medium), or Civilian Crowd (Large) unit.

            4. Click on the terrain to place the unit.


            1. Crowd Tasks

              Crowds can execute some of the tasks available to other ground units. They have the following movement tasks:

              • Crowd around a location.

              • Crowd around an object.

              • Gather in front of an object.

              • Flee.

              • Wander.

              • Protest.

              • Disperse Crowd.


        image

        i

        i

        When a crowd gathers around a location or object, VR-Forces calculates a target destination for each member of the crowd and each member of the crowd tries to move to that destination. If you send two or more crowds to the same location or object, these target destinations may overlap. Individual entities may give up on their movement tasks or may end up very close to members of the other crowd.


        image


        For details about each task, please see its section in Chapter 30, Embarkation, Wait, Radio, and Other Tasks.


          1. Creating Multiple Simulation Objects

            You can add multiple simulation objects to a scenario in one operation and assign them a common task. The simulation objects are added to the scenario as members of a selec- tion group. (For information about selection groups, please see “Using Selection Groups,” on page 17-7.) Creation of multiple simulation objects has the following constraints:

            • The simulation objects are added within a specified area. If an appropriate area does not already exist, you can create one as part of the simulation object creation process.

            • If the area in which you want to place simulation objects overlaps navigation data, the simulation objects are placed only in the portion of the area that has navigation data, as illustrated in Figure 21-1.

            • If the area you choose for placing simulation objects is too small to contain the number of simulation objects that you specify, some simulation objects might not be created.

              When you create multiple simulation objects, VR-Forces automatically puts them in a selection group named group_number, where number starts at 0 and is incremented for each group created.

              In Figure 21-1, Area 1 overlaps the navigation data. If, for example, you try to place 25 entities in this area, they are placed only in the portion of Area 1 that overlaps naviga- tion data, and only the number of simulation objects that fit in this subset of Area 1 are created.


              image

              i

              i

              • If VR-Forces cannot create the number of simulation objects specified (due to one of the reasons mentioned in this section), there is no notifica- tion. It is your responsibility to check to see how many simulation objects were created.

              • Creating multiple simulation objects as described in this section is not the same thing as pattern of life traffic generation or creating simulation object groups. It is just a way to create a lot of simulation objects at one time and give them a task. And unlike creating crowds, which only contain civilians, you can create any type of simulation object.


        image



        Terrain


        Area 1


        navigation data

        Terrain


        Area 1


        navigation data

        image

        Figure 21-1. Placement of multiple simulation objects

        When you create multiple simulation objects you can ask VR-Forces to run an accessi- bility check before it creates each simulation object. VR-Forces tries to ensure that the simulation object being created can reach a specified waypoint from a candidate loca- tion in the specified area. This check is primarily designed to avoid putting simulation objects on top of buildings that are unreachable and would not allow the simulation object to leave the building. It works as follows:

        • If the terrain does not have navigation data, the accessibility check is disregarded and the simulation objects get created.

        • If the terrain has navigation data and if the candidate location cannot use naviga- tion data to reach the waypoint, VR-Forces does not create the simulation object at that location. It tries to find another location at which to place the simulation object. If after multiple attempts to place a simulation object the accessibility check still fails, VR-Forces proceeds as follows:

          • If this is the first simulation object that VR-Forces has tried to create, the accessi- bility check is disregarded and VR-Forces creates the simulation objects (within the constraints previously mentioned).

          • If the accessibility check fails for any simulation object after the first simulation object was created, VR-Forces assumes there is no more space in which to create simulation objects and stops trying to create them.


        To add multiple simulation objects to a scenario:

        1. Choose Create Multiple Simulation Objects. The Create Multiple Simulation Objects dialog box opens (Figure 21-2).


          image

          Figure 21-2. Create Multiple Simulation Objects dialog box

        2. Optionally, change the name of the selection group.

        3. In the Select Area group box, type the name of the area in which you want to create the simulation objects, or select the area from the list or on the map. If the area in which you want to create the simulation objects does not exist, add a new area as described in “Adding an Area for Multiple Simulation Object Creation,” on

          page 21-8.

        4. In the Define Entities To Create group box, add the simulation objects that you want to create. For details about this part of the procedure, please see “Specifying the Simulation Objects to Create,” on page 21-8.


        5. Optionally, edit or remove any of the entity sets listed in the Define Entities To Create list.

        6. Optionally, select the Accessibility Check check box. If you select this check box, select a waypoint. You can create a waypoint from this dialog box if necessary.

        7. Click Create. The entities are created in the specified area.


            1. Adding an Area for Multiple Simulation Object Creation

              To add an area from the Create Multiple Entities dialog box:

              1. In the Select Area group box, click Add. A Create Area tab is added to the window.

              2. Create an area following the standard VR-Forces procedure for creating areas. For details, please see “Placing Objects,” on page 16-11.


            2. Specifying the Simulation Objects to Create

              When you add multiple simulation objects to a scenario, you can specify any of the supported object types and assign a common task or set data request to a specific set of simulation objects.

              To specify the simulation objects to add in the Create Multiple Entities dialog box:

              1. In the Define Entities to Create group box, click Add. The Add Group of Entities dialog box opens (Figure 21-3).


                image

                Figure 21-3. Add Group of Entities dialog box

              2. In the Number of Entities box, specify the number of simulation objects you want to add for this set.

                Crowds and Multiple Simulation Objects — Pedestrian-Oriented Tactical Graphics

                image


              3. Click the Select button that is next to the Type of Entity text box. The Entity Type dialog box opens. The list of object types available is the same list of simulation objects provided on the Simulation Objects Palette.

              4. Select the object type you want to add. The dialog box closes and the object type is listed in the Type of Entity box.

              5. Optionally, specify a starting set data request by clicking the Sets button and selecting a set data request. The list is not context sensitive. You must ensure that the selected set data request is appropriate to the object type that you are adding.

              6. Optionally, specify a starting task by clicking the Tasks button and selecting a task. The list is not context sensitive. You must ensure that the selected task is appro- priate to the object type that you are adding.

              7. Optionally, select an option in the Placement group box. VR-Forces will try to place the simulation objects in the desired location.

              8. Optionally, set a speed and variance range.

              9. Click OK. The object set is added to the list in the Define Entities To Create group box (Figure 21-2).

              10. Optionally, add additional object sets.


          1. Pedestrian-Oriented Tactical Graphics

            VR-Forces has the following tactical graphics that are particular to pedestrians. These objects only work in navigation areas.

        Crowds and Multiple Simulation Objects — Pedestrian-Oriented Tactical Graphics

        image

        21.5.1. Using Civilian Visit Points

        Civilian visit points are waypoints that attract the attention of civilian entities that are walking nearby. The civilians can be members of a crowd or individual entities. When a civilian comes within a configurable distance of a civilian visit point, it stops and faces the point a configurable percentage of the time. If it stops, it waits a few seconds and then continues its task.

        This behavior is controlled by the Visit Interest Points reactive task. You can edit the parameters that control an entity’s behavior in the Manage Reactive Tasks dialog box. For more information about reactive tasks, please see “Reactive Tasks,” on page 26-12.


        image

      4. Modeling Units


        VR-Forces has two, quite different, ways to model simulation objects – entity-level modeling and aggregate-level modeling. These modeling approaches affect how units are modeled.

        The chapters in this section provide conceptual background about modeling units, how to create them, and how to display them.



        VR-Forces Users Guide

        Section IV - Modeling Units


        IV-1

        Modeling Units

        image


        Section IV - Modeling Units

        IV-2 VT MAK


        image 22. Entity-Level Unit Modeling


        This chapter describes how units are modeled in entity-level scenarios.

        Units in Entity-Level Scenarios 22-2

        How Units Are Organized 22-3

        How Units Move 22-4

        How Units Carry Out Tasks 22-5

          1. Units in Entity-Level Scenarios

            In entity-level scenarios units are simulated in either of two states:

            • Disaggregated: Subordinates are simulated and published as individual entities (Figure 22-1). The members of a unit can move individually through the scene, have their own plans, interact with other simulation objects, and do all the things you would expect of an individual entity. When a unit engages in combat, the indi- vidual members of the unit fight the opposing forces using their weapon systems and survive or die as individuals.

              Units in this state can be tasked and given plans, but usually pass responsibility for execution to their subordinates. For example, if you give a disaggregated unit a movement task, each member of the unit plots a path and follows it.

            • Aggregated: Subordinates are not simulated separately. Tasks and plans are executed by the unit. For example, if you give an aggregated unit a movement task, the object representing the unit moves.



              Plt 1 Plt 2


              image image


              image

              Disaggregated Aggregated


              Figure 22-1. Disaggregated and aggregated units


              image

              i

              i

              • The disaggregated and aggregated states are not the same as expanded and collapsed units (which are explained in “Expanding and Collapsing Units,” on page 25-2.). Expanded and collapsed units are simply different visual representations of the unit. Aggregated and disaggregated states are different simulation states.

              • An aggregated unit in an entity-level scenario is similar to a unit in an aggregate-level scenario in that there is no representation of subordinates. However, an aggregated unit can disaggregate and model subordinates, whereas a unit in an aggregate-level scenario cannot do so. Furthermore, their underlying modeling is completely different.

              • Although it is theoretically possible for an entity-level scenario to have units that cannot be disaggregated into individual vehicles and persons, EntityLevel.sms does not have any units of this type.


        image


        A unit can support either of these states. At any given time, one subset of components and systems is enabled, and the other is disabled. At runtime, you can switch dynami- cally between these states.

        You can configure VR-Forces so that unit state is determined automatically according to a set of rules, or to have unit state controlled manually.

        The choice of whether or not to simulate units in the aggregated or disaggregated state depends on your goals for the simulation. For example, if you need to support large numbers of simulation objects, and do not want or need to simulate individual entity behavior, then you may want to simulate some or all of your units in the aggregated state. Conversely, if you need to simulate the detailed behavior of subordinates, then you will want to simulate units in the disaggregated state.


        image

        !

        !

        A unit in the aggregated state only simulates movement behavior. It does not model combat behavior. If you want a unit to model attrition, simulate it in the disaggregated state. A unit in the aggregated state keeps track of its current resource and attrition state. If a unit later transitions to a disaggregated state, this state information is preserved.


        image


        For more details about the differences between aggregated and disaggregated units, please see Chapter 24, Creating and Controlling Units.


            1. How Units Are Organized

              The organization within a disaggregated unit is based on the echelon ID of each member. For example, in Table 22-1, four unique entities (identified by name) are assigned designators in 2 Plt.

              image

              Table 22-1: Example of names and echelon IDs


              Name Echelon ID

              Name Echelon ID

              Tank 1 1 M1A2, 2 Plt, 1 Force

              Tank 2 2 M1A2, 2 Plt, 1 Force

              Tank 3 3 M1A2, 2 Plt, 1 Force

              Tank 4 4 M1A2, 2 Plt, 1 Force

              image


              Assignment of echelon IDs is handled automatically by VR-Forces when you create a unit.


              Reorganizing Units

              Reorganization is the reassignment of echelon IDs to the members of a unit when a member gets destroyed. If reorganization is enabled, when a member of a unit gets destroyed, the destroyed member is assigned the highest numerical ID in the unit, and the surviving members' echelon IDs are moved down numerically by one. For example, assume a platoon as shown in the leftmost table in Figure 22-2. If 2 M1A2 (currently the entity named Tank 2) gets destroyed, reorganization would result in the new echelon ID assignments illustrated in the rightmost table. The former 3 M1A2 is now 2 M1A2, former 4 M1A2 is now 3 M1A2, and the former 2 M1A2, is now 4 M1A2. Their echelon IDs have changed. Their names and object IDs have not.


              image image

              Echelon ID Name

              image

              1. M1A2 Tank 1

                image

              2. M1A2 Tank 2

              3. M1A2 Tank 3

              4. M1A2 Tank 4

                Echelon ID Name

                image

                1. M1A2 Tank 1

                2. M1A2 Tank 3

                3. M1A2 Tank 4

                4. M1A2 Tank 2


                image image

                Figure 22-2. Reorganization of Platoon 2

                You can configure VR-Forces to reorganize units automatically, or you can reorganize manually. Manual reorganization does not require you to reassign each designator; you simply order the unit to reorganize with the Reorganize command.


                image

                i Reorganization only applies to disaggregated units.

                image

            2. How Units Move

              When an aggregated unit receives a movement command, VR-Forces calculates the path it must follow. Then it moves to the location similarly to any individual entity. The unit icon is placed at the center of the bounding box of the area that would be encompassed by the unit if it was disaggregated.

              When a disaggregated unit receives a movement command, VR-Forces calculates the path the unit leader must follow for movement. Then it calculates parallel paths (taking into account the formation) for each member of the unit. The unit members are then responsible for following these paths until the unit completes the movement task.


              Closing Formation

              VR-Forces can close up holes in formations that are created when a unit member is removed from a formation. When a unit is ordered to form up, it assigns formation positions to each of its members. Each position in the formation has an internal ID. If at some point one or more of the unit's members are destroyed, removed, or inde- pendently tasked, the unit reassigns the formation IDs for its list of members. Members that are removed, destroyed, or independently tasked, are not given formation IDs. The active members are moved up in the formation to fill the vacancies. Assignment to a different formation position has no effect on echelon designator.

              The process of closing formation is internal to a unit. Formation position is not reported as part of simulation object information. The only way to determine a simula- tion object’s formation position is to observe the formation as the unit moves.

              Closing formation is an inherent feature of units in the VR-Forces application. You do not need to do anything to put it into effect and you cannot turn it off.


              Closing Formation Versus Reorganization

              Closing the formation of the entities in a unit is not the same thing as reorganization. Reorganization changes the echelon designators of its members. Closing formation does not change the echelon designators of unit members, or the tasks a simulation object is assigned. It only affects the relative positioning of members within a formation.


            3. How Units Carry Out Tasks

        Like other simulation objects, each unit has a plan and you can assign independent tasks to units. When a disaggregated unit is given a task, it sends radio messages to its subordinates directing them to carry out their role in the task, for example, getting into formation and moving to a waypoint.

        If a unit is in the aggregated state, it does not send task messages to subordinates. However, if while carrying out its task the unit disaggregates, it sends appropriate task messages to its subordinates to continue with the task execution. For example, suppose a unit is moving to a point and its path to the point passes through a disaggregation area. When it enters the disaggregation area, it would disaggregate, calculate routes for its subordinates, and send them Move Along Route tasks. When the unit exits the disaggregation area, it aggregates again and the tasks for its subordinates are abandoned.


        image

        i

        i

        Disaggregation areas are special control objects. If automatic aggregation and disaggregation is enabled, when a unit enters a disaggregation area, it automatically disaggregates. When it leaves the area it aggregates. For more information, please see “Using Disaggregation Areas,” on page 24-12.


        image


        The precise way in which a unit sends out messages to its subordinates is part of the modeling of the unit that is built into the VR-Forces application.


        image

        23. How Aggregate-Level Modeling Works


        This chapter describes the aggregate warfare model and how simulation objects created using AggregateLevel.sms work.

        The Aggregate Warfare Model 23-2

        Unit Combat 23-3

        Unit Footprints 23-4

        Unit Posture 23-4

        Unit Movement 23-6

        Limited Munition Attack 23-7

        Contamination Areas 23-7

        Unit Sensors 23-8

        Combat Engineering Objects 23-9

        Concealed Obstacles 23-11

        Creating Combat Engineering Objects 23-11

        How Engineering Units Create Engineering Objects 23-12

        Logistics 23-13

        Receiving Supplies 23-15

        Providing Supplies 23-15

        Electronic Warfare 23-16

        Jamming Communications 23-16

        Jamming Radar 23-17

        Sensing Electronic Emissions 23-18

          1. The Aggregate Warfare Model

            VR-Forces supports a warfare model for aggregate-level scenarios. The aggregate warfare model requires use of AggregateLevel.sms or a similar SMS and only works with HLA Evolved and the MAK FOM extensions.

            The aggregate warfare model is data-driven. Simulation objects have combat power and combat vulnerability. Their overall state is expressed as their health. These are abstract values that represent relative strengths of different units.

            When opposing force simulation objects come into contact, they inflict damage on each other until one of the simulation objects is destroyed or breaks off combat. A unit is considered killed when its health is 0.

            Some of the features that distinguish aggregate-level scenarios from entity-level scenarios include:

            • Footprint. The area occupied by the unit.

            • Posture. The unit’s mode of interaction with the environment.

            • Logistics. Management of personnel and matériel.

            • Combat engineering objects. Tactical graphics that affect simulation object move- ment and health.

            • Electronic warfare. The ability to jam communications.

            • Reports. Some data tracked in a simulation, such as personnel levels and pacing and tracking, is not used by the back-end. It is sent over the network to be used by command and control systems and human participants.


        image

        i

        i

        AggregateLevel.sms includes some individual entities, such as surface vessels and aircraft. However, these entities also use the aggregate warfare model. They do not behave like they would if you were using the same entity types in entity-level modeling.


        image


            1. Unit Combat

              Combat power is the ability of a simulation object to cause casualties and damage, and is a function of how many weapons it has, the size (destructive power) of their muni- tions, the rate of fire of the weapons, the accuracy of the weapons, and the effectiveness of the subordinate simulation objects in conducting an attack (tactics, coordination, target selection, and so on).

              A simulation object’s ability to engage in combat is expressed as a strength value in one or more of the following five domains:

              • Anti-air

              • Anti-tank

              • High explosive

              • Anti-personnel

              • Anti-ship.

                The strength value describes the attrition rate per second imposed on the target by the attacking unit.

                A combat domain has a range. When an opposing force simulation object is within the range of a combat domain for which a simulation object has strength, it attacks the simulation object.

                Health is a function of the amount of equipment, personnel, or both in the simulation object, and the difficulty in destroying them. For example, a unit with 10 tanks would have twice the health of a unit with 5 of the same kind of tank. However, note that the initial health for a unit is set by the SMS designer in the Simulation Object Editor. It is independent of other parameters or resource variables. It is not computed based on the equipment in the unit. Also, health values in different domains are not usually compa- rable to each other. They are only meaningful relative to units in the same domain.

                Simulation objects also have a vulnerability in each of these domains. Base vulnerability describes how susceptible a simulation object is to a given category of weapon. In particular, it describes how easy it is to hit and kill the equipment in the simulation object with the given category of weapon. For example, infantry is very susceptible to high explosive munitions, light armor fairly susceptible, and heavy armor not very susceptible.

                Vulnerability is expressed as a modifier of the combat power (attrition rate) of the attacker. It is multiplied by the attrition rate to calculate the actual damage. For example, a Mech Inf CO US has an Anti-personnel strength of 78. A Mech Inf CO RU has an Anti-personnel vulnerability of .1. If the US company attacks the Russian company, the actual damage for personnel will be 78 * 0.1 = 7.8 per second.

                Both combat power and vulnerability are modified by a variety of factors, including posture, MOPP level, sector, and morale. The combination of all modifiers results in the final attrition rate.


                The attrition across all domains is applied to the simulation object’s health. If health declines to 0, the simulation object is killed.


            2. Unit Footprints

              A unit footprint is an abstract representation of the area the unit occupies with vehicles, personnel, and equipment. A unit takes damage from events that occur within its phys- ical footprint, such as explosions or other simulation objects firing into that area.

              The physical footprint has four sectors: front, rear, left flank, and right flank. The inter- actions of the unit with other simulation objects in the scenario varies based on which sector another entity is encountered on. For example, a unit is typically much more vulnerable to attack on the rear and flank sectors.

              Both the physical footprint size and the size of the sectors for a unit are configured with a base value, but can then change during the scenario depending on actions of the unit.


              image

              i The footprint is always circular. The footprint parameter describes the radius.

              image

            3. Unit Posture

              Posture is an abstraction of the positioning of the equipment and personnel of a unit within its physical footprint, and its state of readiness for various activities.

              The supported postures are:

            4. Unit Movement

              Units try to move at their ordered speed. The movement speed of a unit over the terrain depends on many factors, including the following:

            5. Limited Munition Attack

              Most aggregate-level combat is automated and continues until a combatant is killed or combatants run out of ammunition. There are no specific fire or detonation interac- tions involved and combat essentially takes place in the background. The aggregate warfare model also supports limited munition attacks, in which a limited amount of munitions are used and the attack then ends. In the case of artillery, this is a specified number of rounds from a battery, delivered over a short time. In the case of large muni- tions such as missiles and bombs, the attack for each munition is generally instanta- neous. VR-Forces does not model the time it takes for a munition to reach its target.


              image

              i

              i

              Not all missile attacks are modeled as limited munition attacks. Anti-tank missiles in ground units, for example, are launched by multiple launchers in the unit against multiple targets in the defender, and are modeled with normal combat power.


              image


              Individual missile attacks typically make use of a hit factor from the attacker and a defense factor from the defender to determine a hit probability. The missile must hit before its combat power is applied in an attack.


            6. Contamination Areas

              The aggregate warfare model supports nuclear, biological, and chemical contamination areas (NBC areas) that may damage or impede a unit. You can create contamination areas as tactical graphics, or simulation objects with nuclear, biological, or chemical weapon systems can create them as a result of attacking with these weapons.

              Contamination areas have parameters that are similar to other areal tactical graphics, plus the following parameters:

            7. Unit Sensors

        Simulation objects in aggregate-level scenarios use the same sensor signature mecha- nism as simulation objects in entity-level scenarios. Sensor systems allow them to detect other simulation objects in various domains. Sensor signatures indicate how detectable they are by other simulation objects in the applicable domains. The main difference between simulation objects in the two types of modeling is in the detection checks.

        Simulation objects in entity-level scenarios do a line-of-sight check from the center of the simulation object . Simulation objects in aggregate-level scenarios do three checks – from the center of the outer ring of the footprint and from the edges of the circumfer- ence of the footprint, as illustrated in Figure 23-1.



        image

        Footprint Footprint


        Figure 23-1. Aggregate-level sensing


          1. Combat Engineering Objects

            VR-Forces supports a variety of combat engineering objects that affect unit movement. They may cause a unit to go more slowly or they may damage the unit. Combat engi- neering objects (CEOs), such as fortifications, can also protect a unit, in that they affect the effectiveness of opposing forces.

            CEOs are displayed as tactical graphics. You can create combat engineering objects from the Hazards/Obstacles Palette. Also, units can create combat engineering objects in response to combat engineering object tasks.

            Units can counter the presence of combat engineering objects by breaching them, bridging them, defusing them, or destroying them.

            Combat engineering objects can have the following effects on units:

            • Mobility. CEOs can decrease entity mobility. Mobility modifiers are configured by mobility type. For instance, an object might affect the mobility of soldiers on foot more than tanks. When a simulation object comes in contact with an engineering object, it checks the object type’s mobility modifier against the entity’s mobility type. The entity slows down based on the modifier value.

        The modifier is scaled based on the completion percentage of the object. Modifiers only affect the maximum speed, so speed is affected only if the modified maximum speed is less than the current speed of the unit.

        If a unit encounters an obstacle that obstructs its movement or may cause damage, it stops moving and sends a message to the console indicating that it is obstructed (Figure 23-2). The user must then tell it what to do. The console message may use the question and answer capability. (For information about console questions, please see “Answering Questions from Scripted Tasks,” on page 18-34.)


        image

        i The unit may not be able to move until you respond to the question.

        If an obstacle is concealed, the unit does not stop. For information about

        concealed obstacles, please see “Concealed Obstacles,” on page 23-11.


        image


        The modifier is scaled based on the completion percentage of the object.



        image

        Figure 23-2. Question in entity console

        The modifier is scaled based on the completion percentage of the object.

        The various modifiers are configured for each CEO in the Simulation Object Editor.


            1. Concealed Obstacles

              By default, minefields, booby traps and unexploded ordnance objects are concealed. (This attribute is configurable in the Simulation Object Editor, so you can set it for other objects if you want to.) The engineering object sensor does not automatically detect concealed objects within its sensing radius. The sensor has a random (configu- rable) chance of detecting the object each sensor cycle that the object is within range.

              If a sensor detects a concealed minefield, the Mark Minefield reactive task marks it as detected. Thereafter, the minefield is always 100% detectable. (The Mark Minefield reactive task is enabled by default.)

              Unit movement systems check the concealed flag for obstacles. For non-friendly obsta- cles that are concealed, the “stop and ask” behavior is suppressed unless the object has been specifically detected by the sensor. Therefore, if the sensor has not detected the object, the unit enters it without first stopping and alerting you to the presence of the object.

              Concealed objects are always discovered if they are causing damage to a simulation object.


            2. Creating Combat Engineering Objects

              You can create combat engineering objects directly from the Hazards/Obstacles Palette or you can task simulation objects with the appropriate systems, such as combat engi- neering units, to create them.

              Combat engineering objects are implemented as points, lines, and areas, so you can create them the same way that you would create tactical graphics. Most areal CEOs are fixed size, which is configurable in the Simulation Object Editor. You just have to specify the lower left corner of the area.

              When you create a CEO from the Hazards/Obstacles Palette, you can give it a name, specify a layer and set all the parameters you would expect for that type of object. When you task a unit to create a CEO, it is given a default name and you can only specify its location.

              Many tactical graphics have the same default names as CEOs, for example, fortified lines and minefields. They may also look the same on the map. However tactical graphics do not affect unit movement and combat the way that CEOs do. To help distinguish tactical graphics from CEOS, CEOs created by units are placed on the Combat Engineering Object layer. It is recommended that if you create CEOs from the Hazards/Obstacles Palette, that you place them on the CEO layer.


            3. How Engineering Units Create Engineering Objects

              When a unit with engineering capabilities creates a CEO, it expends construction material at a rate specified in the object’s model (configured in the Simulation Object Editor). Depending on the type of objects, the process can take hours of simulation time.

              While an object is partially complete, its effectiveness is reduced. Some effects, such as enabling mobility over previously impassable terrain (for example by using bridges), do not take effect until the object is complete.


              image

              i

              i

              You can follow the progress of object construction in two ways. You can view the engineering unit’s use of construction material on the Supplies page of its Information dialog box. You can view the percent of the object’s completion on the Engineering Object Information page of the Information dialog box for the object (Figure 23-3).


              image



              image

              Concertina supply Barbed wire under construction Percent complete


              Figure 23-3. Road under construction

              Units create combat engineering objects as follows:

              1. The unit moves within range of the location to create the object.

              2. The unit creates a new object that is 0% complete. The object is displayed on the terrain.

              3. The unit begins constructing the object. As it does so, its supply of construction material decreases.

              4. When the object is complete or the unit runs out of construction material, it ends the task.


        If a creating unit is interrupted and must halt construction, it notifies that object that construction has stopped. The object stays at its current level of completion, which may or may not be useful, depending on the object type. A constructing unit might also reduce its rate of construction if it takes damage.

        If the constructing unit is able to resume construction or another unit is tasked to improve the object, it moves within range of the object and construction starts again.

        Multiple units with construction capability can work together. To task a second unit to assist the first, task it to improve the object under construction.

        You can also set the completion percentage of a combat engineering object with the Percent Complete set data request.


          1. Logistics

            Simulation objects have resources, such as fuel, ammunition, and food. Over time, and particularly during combat, these resources are consumed. Logistics is the process by which a unit resupplies itself.

            Units can resupply the following resources:

            • Health

            • Food

            • Water

            • Motor gas

            • Aviation fuel

            • Diesel fuel

            • Oil

            • Lubricant

            • Anti-Tank

            • High-Explosive

            • Anti-Personnel

            • Anti-Air

            • Anti-Ship

            • Large-Munition

            • Other.

              Anti-Tank, High-Explosive, Anti-Personnel, Anti-Air, and Anti-Ship refer to ammuni- tion in that category. There is no distinction made between different ammunition names within a category. Large-munition covers all other categories of ammunition, such as indirect fire munitions, bombs, and missiles. Other supplies covers any other type of supply, including engineering materials.

              How Aggregate-Level Modeling Works — Logistics

              image


              The Supplies page on the Information dialog box indicates when a simulation object is receiving or providing supplies. You can display supply lines that show when a supply unit is supplying another unit (Figure 23-4). In Figure 23-5, green arrows show the supplies that the entity is receiving.


              image

              Figure 23-4. Supply information and supply lines


              image

              Figure 23-5. Supplies being received


                  1. Receiving Supplies

                    Units can receive supplies in the following ways:

                    • Take supplies from a supply unit. Units take supplies from a friendly supply unit that is within range and has notified them that it can provide supplies. The resupply range is specified in the Simulation Object Editor as part of a supply system.

                    • Auto Resupply Continuously. Supplies increase continuously at a configurable rate.

                    • Auto Resupply Periodically. Simulation objects refill all supplies at specified inter- vals. The interval is configurable.

                      The ability to resupply can be restricted if a simulation object is moving, attacking, or defending. This is configured in the Simulation Object Editor on the Supplies tab. You can change how a simulation object receives supplies using the Set Resupply Mode task. If they are configured for airborne refueling (Can Receive Fuel While Airborne param- eter), airplanes can receive fuel while they are flying, but must be on the ground to receive any other type of supply.


                  2. Providing Supplies

              Simulation objects can provide supplies to other simulation objects if they have a resupply system (resupplier.sysdef). A supply unit can be configured to provide any of the supplies that are supported. A supply unit can provide supplies to any number of other simulation objects. It is assumed to have its own supply source, so it never runs out. You can change a supply unit’s status with the Change Supplying Command task.

              A supply unit runs a background process that tests for friendly simulation objects in its area and notifies them that it is available to provide supplies. It checks for conditions that might prevent a simulation object from receiving supplies. It stops providing supplies to simulation objects that move out of range.


          2. Electronic Warfare

        The aggregate warfare model supports three types of electronic warfare – communica- tions jamming, radar jamming, and sensing electronic emissions.


            1. Jamming Communications

              Each unit has an EW-Comms-Dependence and an EW-Defense-Strength property. The dependence property indicates how much it can be affected if its communications are jammed. The defense factor indicates how well its technology and practices protect it from communications jamming. Units also have, in their state properties, a list of jamming attacks being made against them (type and strength) and a net EW-Comms- Degradation-Percentage.

              When a simulation object attacks another entity with jamming, it sends EW attack information to the target.


              image

              i

              i

              Simulation objects jam all enemy simulation objects in range; there is no target selection. Friendly simulation objects are not affected.


              image


              When a simulation object suffers communications jamming attacks, the strengths of all attacks are added together and compared to the defensive strength. The ratio deter- mines a modifier between 0 and 1, which is multiplied by the EW-Comms-Depen- dence. The result is a degradation percentage. This degradation percentage is applied to reduce combat power, and increase vulnerability and posture change time (by a maximum factor of 2.0).

              Units can have a system called an aggregate-comms-jammer. This system has parame- ters for strength, maximum range, and a set of allowed postures. Strength falls off with 1/r2 (r is range in kilometers). This system can trigger EW attacks using the Make EW

              Attack background scripted task. It has a jammer controller that can publish an emitter.

              You can enable or disable the emitter using the Emitter set data request. Turning it on activates jamming, and turning it off deactivates jamming. If the emitter is turned on while the simulation object is not in an allowed posture for jamming, a warning is printed to the console. In this case the emitter is on, but it is not used for jamming attacks.

              When jamming is enabled the Make EW Attack script determines which jamming systems on the simulation object are on, and then uses them to attack all targets within range. It updates (new) EW-Attacks and Jamming-Strength-On state properties on the simulation object. The Jamming-Strength-On property summarizes the strength from all jammers the simulation object has turned on, and is used for emissions sensing. The Update_EW_Degradation background script computes the effects of EW attacks on a simulation object.

              How Aggregate-Level Modeling Works — Electronic Warfare

              image


              The MI PLT (military intelligence platoon) unit is configured to have an aggregate- comms-jammer.


            2. Jamming Radar

              Each unit has a state property Radar-Jamming-Strength-Receiving, which is updated by the Update_EW_Degradation background script. This is the total radar jamming strength being received.

              Radar jamming can have the following effects:

              • Reduce the sensitivity of radar sensors so they cannot detect targets.

              • Reduce the hit factor of radar-homing missiles so they have a smaller hit proba- bility.

                The active-radar-sensor system has a parameter called jamming-defense-factor. This factor reflects the technology of the radar (not power) and is used with the jamming strength received to compute a sensitivity modifier for the sensor. The modifier varies from 0 to 1.

                The weapon systems that use a controller that uses an aggregateReleaseBombControl- lerDescriptor have parameters can-be-radar-jammed and jamming-defense-factor. This includes the following weapon systems:

              • aggregate-antiair-missile

              • aggregate-antiship-missile

              • aggregate-land-attack-missile

              • aggregate-release-bomb

              • aggregate-unguided-bomb.

                If can-be-radar-jammed is true, then jamming-defense-factor is used with jamming strength received to calculate a modifier for the hit factor of the weapon.

                Weapon systems are configured with either a constant or variable for can-be-radar- jammed, to provide examples of different guidance systems:

              • Anti-air missiles use a variable, to allow modeling of IR or radar-homing missiles.

              • Anti-ship missiles set can-be-radar-jammed true, thus assuming radar guidance.

              • Land attack missiles use a variable.

              • Release-bomb omits the parameter (default is false), to simulate optical guidance.

              • Unguided bomb omits the parameter (default is false).

                The aggregate-radar-jammer system can publish an emitter and can be turned on and off using Emitter set data request. It enables the EW_Attack script.

                The radar jammer strength falls off with 1/r2 (r is range in kilometers). The EA-18G entity is configured with a radar jamming system.


            3. Sensing Electronic Emissions

        The emission sensor domain allows simulation objects to sense RF electromagnetic emissions from simulation objects. Each simulation object has an emissions signature, which is a parameter for each object type. This can be detected by the SIGINT sensor. This is the “normal background signature”.

        There is a sensor signature modifier for emissions. VR-Forces determines if specific emitters are turned on, thus adding to the normal background signature for the simula- tion object .

        The emissions signature modifier has a parameter, jam-strength-factor, that converts jamming strength to a signature value. It is set in the platform files.

        There is a sensor system emissions-sensor for emissions. It is called a SIGINT (signals intelligence) sensor. The MI PLT unit is configured with a SIGINT Sensor.


        image

        24. Creating and Controlling Units


        This chapter explains how to create and manage units.

        Creating Units 24-2

        Creating a Unit by Combining Existing Simulation Objects 24-2

        Creating a Preconfigured Unit 24-5

        Configuring the Unit Creation State 24-6

        Selecting a Unit 24-6

        Adding Simulation Objects to a Unit 24-7

        Removing a Simulation Object from a Unit 24-8

        Units and Unit State in Entity-Level Scenarios 24-8

        How a Unit’s State is Shown 24-9

        How Changing Aggregation State Affects a Unit 24-10

        Triggering Unit State Transitions 24-11

        Aggregating and Disaggregating Units Manually 24-12

        Configuring Automatic Aggregation and Disaggregation 24-12

        Using Disaggregation Areas 24-12

        Writing Plans for Units 24-12

        Deleting a Unit 24-13

          1. Creating Units

            You can create a unit by selecting simulation objects (which can be individual entities or units) and combining them to form a unit, or by placing a preconfigured unit from the Simulation Objects Palette. In entity-level scenarios, most preconfigured units can be disaggregated to the level of individual vehicles and persons. In aggregate-level scenarios, most preconfigured units cannot be disaggregated.

            When you create a unit, it is created as a subordinate to the force level. You cannot create units that are subordinates of an existing unit. Once you create a unit, you can subordinate it to another unit. (For details, please see “Adding Simulation Objects to a Unit,” on page 24-7).


            image

            i

            i

            Except where noted, the procedures for creating and editing units apply to entity-level scenarios and aggregate-level scenarios.


            image


            1. Creating a Unit by Combining Existing Simulation Objects

              When you create a unit by combining simulation objects, you can specify the order of subordinates in the unit. This determines which subordinate is considered the unit leader and affects the assignment of echelon IDs. (It also affects the icon used to repre- sent the unit.) You cannot change the subordinate order after you create the unit.


              image

              i

              i

            2. Creating a Preconfigured Unit

              EntityLevel.sms and AggregateLevel.sms include preconfigured units at several hierar- chical levels. You can configure them and add additional units in the Simulation Object Editor. (For details, please see “Editing Unit Composition,” on page 66-4.)

              You create preconfigured units by selecting them on the Simulation Objects Palette and follow the standard procedures for creating simulation objects. The abbreviations in the unit names in EntityLevel.sms have the following meanings:

            3. Configuring the Unit Creation State

        This procedure only applies to units in entity-level scenarios.

        To configure the aggregation state used when units are created:

        1. Choose Settings Application. The Application Settings dialog box opens.

        2. Select the Entity Behavior Options page (Figure 24-3).


          image

          Figure 24-3. Entity Behavior Options page

        3. In the Initial Unit State group box, select the creation option that you want.

        4. Click OK.


          1. Selecting a Unit

            To select a unit, select its icon on the terrain, or select it in one of the views on the Objects List Panel.

            Creating and Controlling Units — Adding Simulation Objects to a Unit

            image

          2. Adding Simulation Objects to a Unit

            To add a simulation object to a unit, in the Echelon View, select the simulation object you want to add and drag it onto the unit as illustrated in Figure 24-4. Notice that the name of the simulation object stays the same, but its echelon ID changes.


            image

            i

            i

          3. Removing a Simulation Object from a Unit

            To remove a simulation object from a unit, in the Echelon View, drag the simula- tion object from the unit to the force level in the window, as illustrated in Figure 24-5, or into another unit. Notice that the name of the simulation object stays the same, but its echelon ID changes.


            image

            i

            i

          4. Units and Unit State in Entity-Level Scenarios

        In entity-level scenarios, units can switch back and forth between the aggregated state and the disaggregated state. It is important to understand the differences between these states. The types of units are introduced in Section 22.1, “Units in Entity-Level Scenarios”. This section provides additional details about how units function in the two different aggregation states.


        image

        i The Convoy unit does not support aggregation and disaggregation.

        image

        Creating and Controlling Units — Units and Unit State in Entity-Level Scenarios

        image

            1. How a Unit’s State is Shown

              Units publish their aggregation state using the DIS/RPR FOM aggregate state enumer- ation. The current value for this parameter is displayed on the State Data page in a unit’s Information dialog box (Figure 24-6). It can be accessed in the unit’s DtVrfAggre- gateStateRepository member.


              image

              Figure 24-6. State Data page


              Aggregated State

              When a unit is in the aggregated state, its subordinates do not exist as distinct simula- tion objects. It does not have any subordinates shown in the Echelon View or on the Subordinates page of its Information dialog box. It does not display ghosted icons for subordinates. You cannot expand or collapse it.


              Disaggregated State

              When a unit is in the disaggregated state, its subordinates are simulated as distinct simulation objects. (However, it is possible to have a disaggregated unit with no subor- dinates.) Subordinates are displayed under the unit in the Echelon View and are listed on the Subordinates page of its Information dialog box. You can expand or collapse the unit.

              Creating and Controlling Units — Units and Unit State in Entity-Level Scenarios

              image

            2. How Changing Aggregation State Affects a Unit

        Units can change their aggregation state at runtime. All state information maintained by the unit (for example, the current task it is executing, plan state, current resource levels) is maintained across the transition between aggregated and disaggregated states. This section describes how units handle transitions for the most important activities.


        Movement

        All movement tasks can be executed in either aggregated or disaggregated state. Units can transition between states at any time, without interrupting movement tasks. For example, suppose a unit in the disaggregated state, is executing a move-to-location task. While it is executing the task, you issue a Unit State set data request, indicating it should switch to the aggregated state. The unit transitions into the aggregated state (subordinates are deleted, and the state associated with them is mapped and stored internally in the unit), and continues moving toward its destination. Similarly, making a transition in the opposite direction while executing a movement task, does not inter- rupt the execution of that task.

        Units preserve their formation across unit state transitions.


        Combat

        Only disaggregated units can engage in combat. However, a unit remembers any loss of resources or subordinates while it is aggregated. If a subordinate is destroyed while the unit is disaggregated, it is not created again if the unit aggregates and then disaggregates again.


        Resources

        Resources are tracked and restored across state transitions. However, if a subordinate is destroyed while in the disaggregated state, then all of its resources are lost. They are not redistributed to other subordinates.


        image

        i

        i

        When you restore a unit that is in the aggregated state (using Restore), the original configuration of the unit is recreated. If you restore a unit that is in the disaggregated state, then only those subordinates still present in the simulation are restored. Any destroyed subordinates that were previously removed from the simulation as result of a disaggregate-->aggregate--

        >disaggregate transition are not restored. To fully recover all subordinates, restore the unit while in the aggregated state.


        image

        Creating and Controlling Units — Triggering Unit State Transitions

        image


        Plans and Tasks

        While a unit is disaggregated, its members can be given tasks and plans. However, when the unit aggregates, all tasks and plans are discarded. If the initial unit creation state is set to Aggregated and you create a unit from existing simulation objects, if the simula- tion objects have plans, the plans are discarded. (For information about settings the initial aggregation state, please see “Configuring the Unit Creation State,” on

        page 24-6.)


        image

          1. Triggering Unit State Transitions

            You can initiate unit state transitions manually or automatically, as follows:

            • Manually: You can send a Unit State set data request or use Aggregate and Disag- gregate commands on the Objects menu. This immediately forces the unit to change state. As a set data request, state changes can be included in plans.

            • Automatically: On the Entity Behavior Options page of the Application Settings dialog box, you can configure automatic aggregation and disaggregation. In auto- matic mode, units automatically aggregate or disaggregate according to the following rules:

              • If the unit is within “disaggregation range” of a hostile entity or unit, the unit is in the disaggregated state. Disaggregation range is the range around a simulation object or unit in which you want to force any nearby aggregated units to disag- gregate so you can detect or engage them. This range is configurable for every type of entity and unit in the Simulation Object Editor. (You must show advanced parameters to set this parameter.)

              • If the unit’s formation footprint (projection of its bounding extent in a topo- graphic plane) overlaps a disaggregation area, the unit is in the disaggregated state. (A disaggregation area is a specific type of control object.)

              • If neither of the above conditions is in effect, the unit is in the aggregated state.

        Creating and Controlling Units — Writing Plans for Units

        image

            1. Aggregating and Disaggregating Units Manually

              To aggregate a disaggregated unit:

              1. Select the unit.

              2. Choose Objects Aggregate.


                image

                i

                i

                You can also change a unit’s state with the Unit State set data request (which also means that you can change state from within a plan).


                image


                To disaggregate an aggregated unit:

                1. Select the unit.

                2. Choose Objects Disaggregate.


            2. Configuring Automatic Aggregation and Disaggregation

              To configure automatic aggregation and disaggregation:

              1. Choose Settings Application. The Application Settings dialog box opens.

              2. Select the Entity Behavior Options page (Figure 24-3).

              3. In the Aggregate/Disaggregate group box, select Automatically or Manually.

              4. Click OK.


            3. Using Disaggregation Areas

        When an aggregated unit that has automatic aggregation and disaggregation enabled enters a disaggregation area, it disaggregates. When it leaves the area, it aggregates again. A disaggregation area is a control object. You create one just like any other area, as described in Chapter 16, Creating and Placing Objects.


          1. Writing Plans for Units

            To write a plan for a unit, follow the procedures for writing a plan for a simulation object in Chapter 36, Writing Plans.


            image

          2. Deleting a Unit

            Creating and Controlling Units — Deleting a Unit



            image

            ! If you delete a unit, all its members get deleted.

            image

            To delete a unit:

            1. Select the unit.

            2. Choose Objects Delete.

        Creating and Controlling Units — Deleting a Unit

        image


        image 25. Displaying Units


        Many aspects of managing units are the same as for individual entities. This chapter focuses on features that are unique to units.

        Selecting Units 25-2

        Expanding and Collapsing Units 25-2

        Expanding and Collapsing Units in the Echelon View 25-4

        Expanding and Collapsing the Echelon View by Level of Aggregation.. 25-4 Displaying Ghosted Icons 25-6

        Displaying Unit Icons and Bounding Volumes 25-9

        Specifying the Color Scheme for Unit Bounding Volumes 25-11

        Displaying Units — Selecting Units

        image

          1. Selecting Units

            You can select units in the same ways that you can select entities. (For details about selecting entities, please see “Selecting Simulation Objects, Tactical Graphics, and Props,” on page 17-4.) However, to select a unit, you must select the unit icon, not individual members of the unit. If a disaggregated unit is expanded, the unit icon might not be visible. To select the unit, you can collapse it, or you can select the unit in the Echelon View.


          2. Expanding and Collapsing Units

            You can display disaggregated units in expanded or collapsed mode. When a unit is collapsed, it is displayed as one icon. When a unit is expanded, all the members of the unit are visible as individual entities or subordinate units and the unit icon is hidden. Multi-level units can expand and collapse at each level of aggregation. For example a company could be collapsed to the company level (one icon), the platoon level (an icon for each platoon), or fully expanded.


            image

            i

            i

            Aggregate-level scenarios do not support aggregation and disaggregation of units. Units are always disaggregated. Therefore, they can always be expanded and collapsed.


            image


            When you Expand or Collapse a unit, you can expand or collapse one level of aggrega- tion or all levels. When you Expand or Expand All, expansion is downward from the current unit and does not affect any sibling units. When you Collapse, contraction is upward in the hierarchy. Collapse All collapses all members of the unit to the topmost level.

            Figure 25-1 illustrates these relationships. Assume a company with three platoons, each of which has four vehicles.

            • If you Expand the top level unit, it expands to the platoon level. (1)

            • If you select Plt C and choose Expand or Expand All, it expands just Plt C. (2)

            • If you select the top level unit and expand all, it expands to the leaf level – 12 indi- vidual vehicles. (3)

            • If the unit is fully expanded and you select one member of Plt C and choose Collapse, just Plt C collapses. (4)

            • If you select any member of an expanded unit and select Collapse All, the entire unit collapses. (5)



        image

        Fully collapsed


        image

        Plt C

        image

        1. Expand image image image


          image

          image

        2. Expand Plt C image image image


          image

          image

        3. Expand All image image image (from top)


          image


          image

        4. Collapse image image image Plt C


          image


          image

          image

        5. Collapse All


        Figure 25-1. Unit expand and collapse


        image

        i

        i

        A unit’s icon does not indicate whether it is aggregated or disaggregated. However you can easily infer its state from the Objects menu or the Echelon View. The unit commands on the Objects menu are context sensitive. If you select a unit and the Disaggregate command is available, then the unit is in the aggregated state. Similarly, if you view a unit in the Echelon View, if it is aggregated, you cannot expand it in the tree. If it is disaggregated, you can expand it to see its subordinates.

        You can also view its state explicitly on the State Data page of the Information dialog box.


        image

        To expand a unit, right-click the unit icon or its entry in the Objects List Panel and choose Expand on the popup menu.

        To expand a unit and all its subordinate units, right-click the unit icon or its entry in the Objects List Panel and choose Expand All on the popup menu.

        To collapse a unit one level, right-click any member of the unit and choose Collapse

        on the popup menu.

        To collapse a unit to its root level, right-click any member of the unit and choose

        Collapse All on the popup menu.

        Displaying Units — Expanding and Collapsing Units

        image

            1. Expanding and Collapsing Units in the Echelon View

              You can expand and collapse units in the Echelon View on the Objects List Panel.

              To expand a unit in the Echelon View, click the plus sign next to its icon.

              To collapse a unit in the Echelon View, click the minus sign next to its icon.


            2. Expanding and Collapsing the Echelon View by Level of Aggregation

        In addition to expanding and collapsing the order of battle on a node-by-node basis, as in typical hierarchical view windows, the Echelon View enables you to view simulation objects by the level of aggregation.

        Individual entities are directly subordinate to the force they belong to. If a simulation object becomes part of a unit, the unit is subordinate to the force and the individual entity is one level further away. Seen another way, you can say that the force is the parent and all other simulation objects in that force are children, grandchildren, and so on.

        The Echelon View displays the simulation objects in columns that are equivalent to their relationship to the force – the first column is children, the second column is grandchildren, and so on.

        At the top of each column in the Echelon View is a plus (+) or minus (-) button that works like the buttons within the hierarchical display (Figure 25-2). A plus indicates that at least one simulation object in that column is a unit and that none of the units in the column are expanded. A minus indicates that at least one unit at that level is expanded. Clicking a minus sign collapses all units in the column. Clicking a plus sign expands all units in the column.

        To change the hierarchical level view in the Echelon View, click the level controls in the horizontal band across the top of the window.

        Figure 25-2 illustrates an Echelon View with several levels of units, some of which are collapsed and some of which are expanded.



        image

        Figure 25-2. Echelon View


          1. Displaying Ghosted Icons

            If you want to select units, you need to collapse them so that you can select the unit icon. However, when you do this, you can no longer see where individual subordinate simulation objects are located and if subordinates are destroyed, you cannot see which ones are destroyed and which are functional. VR-Forces provides the following options for displaying unit icons so that you can work with them in a way that best meets your visualization and simulation object management needs:

          2. Displaying Unit Icons and Bounding Volumes

            VR-Forces lets you configure when to display unit icons and bounding volumes. Bounding volumes are translucent polygons that show the extents of the unit. This is useful when the individual entity icons or models are not displayed. You can configure icons and bounding volumes as follows:

            • Enable and disable the display of units. When disabled, only the 2D icons or 3D models for leaf level unit members are displayed.

            • Enable and disable the display of bounding volumes. Bounding volumes are displayed only for collapsed units. You can restrict the display of bounding volumes to the selected units.

            • In 3D observer modes, enable or disable the display of unit icons.

        Figure 25-6 shows a unit bounding volume in Stealth observer mode, with leaf nodes displayed.


        image

        Figure 25-6. 3D bounding volume


        Figure 25-7 shows a unit bounding volume in Plan View observer mode, with ghosting enabled.


        image

        Figure 25-7. 2D bounding volume

        You can display unit icons without showing bounding volumes and vice versa.

        To configure the display of unit icons and bounding volumes:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Unit Display Settings page (Figure 25-4).

        3. To enable the display of unit icons, bounding volumes, or both, select Show Units.

        4. To display bounding volumes for collapsed units, select Show Bounding Volumes.

        5. To restrict the display of bounding volumes to the selected units, select Show Bounding Volumes Only for Selected Units.

        6. To display unit icons in 3D observer modes, select Show Aggregate Icon (3D Only).


        image

        image

        i

        i

        You can also enable and disable units by choosing Settings Units or by selecting the Units button ( ) on the Display Settings Toolbar.


        image


            1. Specifying the Color Scheme for Unit Bounding Volumes

              Unit bounding volumes can be displayed using primary colors or MIL-STD colors.

              To specify the color scheme to use for unit bounding volumes:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Unit Display Settings page (Figure 25-4).

              3. Select the Force Coloring Settings option that you want (Use Primary Colors or Use MIL-STD Icon Colors).


        image

      5. Tasks and Sets


This section describes tasks, set data requests, and scripted tasks and sets.


    1. Introduction to Tasks

      VR-Forces simulation objects can execute a variety of movement and tactical tasks. These tasks can be assigned in plans or through the Task menu. Tasks assigned outside of a plan are called independent tasks.

      Some tasks are mutually exclusive with other tasks, for example, a simulation object cannot execute two different movement tasks at the same time. Other tasks, such as Send Text Message, can run concurrently with movement tasks. When you task a simu- lation object, if the new task is mutually exclusive with the current task, the simulation object immediately stops the current task and begins the new one. If the new task is not mutually exclusive with the current task, the simulation object executes the new task and continues with the previous task. For information about how to configure mutually exclusive tasks, please see “Configuring Task Execution Rules,” on page 26-35.

      If a simulation object has a plan, when you give it an independent task, it abandons the rest of the plan.

      Independent tasks are useful for assigning tasks to simulation objects without the need to edit a plan. You can assign them interactively, so simulation participants can respond immediately to events in a simulation by assigning new tasks to a simulation object as they might have to do in the field. General issues for assigning tasks are described in detail in Chapter 26, Assigning Tasks. Specific task procedures are in the succeeding chapters.

      Many tasks are implemented as part of the VR-Forces code (C++ tasks) and cannot be added to or changed by end-users. Other tasks, called scripted tasks, are implemented using Lua scripts. You can edit scripted tasks and write new ones. For details, please see “Creating Scripted Tasks and Sets,” on page 32-1.



      VR-Forces Users Guide

      Section V - Tasks and Sets


      V-1

      Tasks and Sets — Introduction to Set Data Requests

      image


      VR-Forces has a special type of scripted task, called a reactive task, that does not get explicitly assigned to simulation objects. Reactive tasks monitor the simulation and run only if certain conditions are met. For information about reactive tasks, please see “Reactive Tasks,” on page 26-12.

      A third type of scripted task is the background process. Background processes run continuously to handle certain types of ongoing aggregate-level activities, such as consuming or receiving supplies, calculating a unit’s footprint, and automatically attacking opposing forces. For information about background processes, please see “Background Processes,” on page 33-30.

      Figure 25-1 illustrates the many ways that a simulation object can have its task, behavior, and state changed.



      Reactive task


      Plan


      Set data request


      Simulation Object


      Innate behavior

      Independent task



      Global command Tasked by superior


      image

      Figure 25-1. Inputs to simulation object actions


    2. Introduction to Set Data Requests

Set data requests affect the state or behavior of a simulation object, such as its speed or posture. They take effect immediately. Assignment of a set data request does not over- ride the task that a simulation object is executing. By contrast, if you assign a simula- tion object a task, it stops its current task and begins the new task. You can send set data requests from a plan or from the Set menu. The various set data requests are described in detail in Chapter 34, Setting the State of Simulation Objects.

You can create new set data requests using the same Lua scripting process that you can use to create scripted tasks.


Section V - Tasks and Sets

V-2 VT MAK


image 26. Assigning Tasks


This chapter provides general details about how to assign tasks to simulation objects. For descriptions of specific tasks and how to assign them, please see Chapter 30, Embarkation, Wait, Radio, and Other Tasks and Chapter 31, Tasks for Aggregate-Level Scenarios.

Assigning Tasks to Simulation Objects 26-3

Task Procedures 26-3

C++ Tasks and Scripted Tasks 26-4

Concurrent Task Execution 26-5

How do I Know which Simulation Object can Execute a Task? 26-7

Escaping the Task Assignment Process 26-7

Specifying Parameters for Tasks 26-7

Viewing Task Status 26-9

Filtering the Object Selection Lists 26-10

Skipping (Stopping) a Task 26-10

Assigning Tasks to Units 26-11

Convoy Tasks 26-11

Independently Tasking Unit Members 26-12

Reactive Tasks 26-12

Enabling Reactive Tasks 26-14

Disabling Reactive Tasks 26-15

Setting the Priority of a Reactive Task 26-16

Managing Reactive Tasks 26-17

Canceling a Reactive Task 26-18

Using Behavior Sets to Manage Scripts 26-19

Creating Behavior Sets 26-20

Editing Behavior Sets 26-21

image

Assigning Tasks

Assigning a Behavior Set to a Force 26-21

Entity Movement On Roads and Off Roads 26-22

Road Driving Behavior 26-23

Fixed-Wing Entity Tasks and Behaviors 26-23

Placement of Newly Created Fixed-Wing Entities 26-23

Fly Task Behavior is Different from Move Task Behavior 26-24

Specifying and Maintaining Altitude for Fixed-Wing Entities 26-25

Fixed-Wing Entity Movement on the Ground and in the Air 26-26

How Fixed-Wing Entities Take Off 26-28

How Fixed-Wing Entities Land 26-29

Rotary-Wing Entity Tasks and Behaviors 26-30

Controlling Rotary-Wing Orientation 26-32

Suppressive Fire Tasks 26-32

Configuring Suppression Effects 26-34

Configuring Task Execution Rules 26-35

Configuring Action Categories 26-36

    1. Assigning Tasks to Simulation Objects

      You can assign tasks to a simulation object as part of its plan, as part of a global plan, and independently of any plan. For conceptual information about tasks, please see “Introduction to Tasks,” on page 25-1. For information about how to add a task to a plan, please see “Adding a Task or Set Data Request to a Plan,” on page 36-4.

      You cannot assign tasks to non-VR-Forces simulation objects. However, you can use a remote simulation object as a parameter in a task, for example, following a remote simulation object, or targeting a remote simulation object. For more information, please see “Using Non-VR-Forces Simulation Objects in Plans,” on page 35-19.


      1. Task Procedures

        For the procedures for assigning tasks, please see Chapter 27, Movement Tasks for Entity- Level Scenarios, Chapter 28, Engagement Tasks for Entity-Level Scenarios, Chapter 29, Human and Crowd Tasks, Chapter 30, Embarkation, Wait, Radio, and Other Tasks and Chapter 31, Tasks for Aggregate-Level Scenarios.

        If your installation uses the VR-Forces API to add additional tasks, consult with your software engineers for procedural information. Please see “Fixed-Wing Entity Tasks and Behaviors,” on page 26-23 and “Rotary-Wing Entity Tasks and Behaviors,” on

        page 26-30, for additional information about assigning tasks to these simulation object types.

        The instructions for creating tasks direct you to use options on the Task menu. However, all the options available on the main menu are also available on context-sensi- tive menus. A limited number of tasks are available on the Tasks Toolbar and on the Last Selected Object Panel.


      2. C++ Tasks and Scripted Tasks

        The VR-Forces application includes a basic set of tasks for movement, weapons fire, and other actions, that were developed using the VR-Forces Toolkit and the C++ API. System integrators often use the C++ API to add additional tasks before delivering VR- Forces to their customers. These tasks are called C++ tasks to distinguish them from another type of task – the scripted task. Scripted tasks, written in the Lua programming language, use the lower-level C++ tasks and the VR-Forces Lua API to build higher- order tasks for simulation objects. You do not need the VR-Forces Toolkit or a devel- opers license to write scripted tasks.

        To the VR-Forces end user, scripted tasks, most of which are listed on the Task menu, are indistinguishable from C++ tasks. For information about scripted tasks, please see Chapter 32, Creating Scripted Tasks and Sets.

        VR-Forces also supports two special categories of scripted tasks called reactive tasks and background processes. These tasks are not on the Task menu. Reactive tasks execute when a condition becomes true. For details, please see “Reactive Tasks,” on page 26-12. Background processes run continuously. They only apply to aggregate-level scenarios. (For details, please see “Background Process List,” on page 31-32.)


      3. Concurrent Task Execution

        Some tasks can execute at the same time. Some are mutually exclusive. If you assign a simulation object a task that is mutually exclusive with its current task, the current task is abandoned. If you assign a task that is not mutually exclusive with the current task, it executes the new task while continuing to execute the previous task.


        image

        i

        i

        When you assign a mutually exclusive independent task, VR-Forces displays a prompt that asks you to confirm interruption of the current task. You can disable this prompt if you always want a new task to interrupt the current task. For details, please see “Enabling and Disabling the Task Confirmation Prompt,” on page 26-6.


        image


        C++ tasks are organized into the following groups:

      4. How do I Know which Simulation Object can Execute a Task?

        Some VR-Forces tasks apply to almost all simulation objects, such as Radio tasks and some movement tasks. Others are valid only for particular platforms or even particular entity types. Sometimes it is obvious which entity types can execute a task. For example, you would expect that Fixed-Wing Land only applies to fixed-wing entities. Similarly, Raise Periscope applies to submarines. However, for other tasks, it is not always evident which simulation object can execute a task.

        Simulation objects can execute tasks for which they have an appropriate controller. They access most task controllers through systems. Therefore, simulation objects can execute the tasks supported by their various movement, weapon, sensor, and other systems. For example, to deploy naval mines, an entity needs a Naval Mine Deploy- ment system.

        To see which systems a simulation object has, and thereby infer which tasks it can execute, you can examine the simulation object’s systems in the Simulation Object Editor. You can also refer to VR-Forces Entity Model Catalog, which lists the systems for each simulation object configured in the Simulation Object Editor. Appendix D, Systems and System Usage lists each system provided with VR-Forces, the types of simu- lation objects it supports, and its description. It also lists each system and the simula- tion objects that are configured to use it.


      5. Escaping the Task Assignment Process

        You can escape the task assignment process at any point before you complete it.

        To escape the task assignment process, in the task dialog box, click Cancel.


      6. Specifying Parameters for Tasks

        VR-Forces lets you specify task parameters in dialog boxes or by selecting them on the terrain. Many tasks require you to select a tactical graphic or a simulation object.

        If you select the appropriate object, the selection is reflected in the task dialog box.

        If you prefer, you can specify all parameters in the task dialog box. Depending on the zoom level of the terrain and the number of simulation objects and tactical graphics you have created, it may be easier to select an object from a list than to select it from a densely packed group of icons.


        Selecting Objects in Multiple List Dialog Boxes

        Some task dialog boxes, such as Patrol Between, require you to select multiple objects, each of which is selected from a different list.

        You can select the objects in the list window or in the display window. At any given moment, one of the lists is the active list and a selection in the display window is reflected in that list. The active list is indicated by the button next to the Filter list (Figure 26-2).


        image

        Figure 26-2. Multiple list dialog box

        The active list is determined as follows:

        • When you first open the dialog box, the first list window is automatically active. If you select an object in the display, it is selected in the first list window. Then the second list window automatically becomes active and the next object you select in the display is selected in the second list window. This sequence continues until all list windows have a selection. Then the last window stays as the active list.

        • Selecting an object in a list window makes it active.

        • Clicking the Filter button image) next to the Filter list makes that list window active. It will stay active until you click the button to inactivate it or click in another list window.

        • If all lists are inactive (by clicking the Filter button to put it into the unselected state), you can click objects in the display without affecting the selections in the list windows.


      7. Viewing Task Status

        The Information dialog box for a simulation object lists its current task on the Tasks page. It also lists the state of the reactive tasks that are enabled for the simulation object. If a simulation object is executing a task as part of its plan, you can see which task it is executing by opening its Plan window (Figure 26-3). You can also see the current task on the Last Selected Object Panel and the Tasks page of the Information dialog box.


        image

        Figure 26-3. Display of simulation object task status


      8. Filtering the Object Selection Lists

        If a task requires you to select objects, you can filter the object selection list to make it easier to find the particular objects you need to select (Figure 26-4). If you are selecting simulation objects, for example in a Follow Entity task, you can display all simulation objects, individual simulation objects only, or units only. Within the latter two groups, you can display friendly or opposing simulation objects. In a Move To task, you can filter for waypoints, friendly simulation objects, or opposing simulation objects.



        image

        Figure 26-4. Simulation object filter list

        To filter a simulation object list, in a task or set data request dialog box, choose the filter type from the list.


      9. Skipping (Stopping) a Task

        You can instruct a simulation object to stop executing its current task. If the simulation object is executing a plan, it moves to the next task in its plan. If there are no further tasks, the simulation object waits for further orders.

        To order a simulation object to skip a task, choose Objects Skip Task.


        image

        i

        i


image


image

    1. Assigning Tasks to Units

      Assigning Tasks — Assigning Tasks to Units

      To assign a task to a unit, select the unit, then assign it a task as you would any individual entity.


      image

      1. Convoy Tasks

        VR-Forces has two tasks for moving in convoys – Convoy Along and Convoy To. These tasks can only be assigned to units made up of ground vehicles. When a unit receives a convoy task, it organizes itself into a column based on the echelon IDs. Then it executes the task.

        Once the task begins, the members of the unit try to maintain a consistent distance apart from each other. You can configure this distance by editing the Ground Convoy Movement system in the OPD Editor. The distance is specified by the separation- distance parameter. You can also specify an amount by which the separation distance can vary using the separation-tolerance parameter.


        image

        i

        i

        If VR-Forces can determine that a convoy task is not appropriate for a given unit, for example a rotary wing unit, the convoy tasks are not available on the Task menu. However, in other cases, such as mixed units or if you aggregate disparate entities as Ground Unit, it is up to you to know whether or not a unit consists only of ground vehicles or contains platforms that do not support convoy tasks.


        image


      2. Independently Tasking Unit Members

        Members of a disaggregated unit can have individual plans or be assigned tasks inde- pendently of the unit. If a member of a unit is independently tasked, when it completes its task it automatically becomes tasked by its superior. You do not need to give it a Tasked by Superior set data request. You can override this behavior by setting an object’s tasked-by-superior-upon-task-complete parameter in the object parameter database to False.

        If a Skip Task command is given to an independently tasked subordinate, it remains in the independently tasked state until it either completes a task or it is given a Set Tasked by Superior set data request.

        When a simulation object becomes tasked by its superior, it does not execute the task that the unit is currently executing. It receives the next task that is sent out by the unit.


        image

        i

        i

        When a disaggregated unit changes to the aggregated state, the individual subordinates cease to exist. Therefore, if a subordinate is executing an independent task, when the unit changes state, the task activity ends immediately.


        image


    2. Reactive Tasks

      Reactive tasks are a special category of scripted tasks. Unlike other tasks (whether scripted or C++), reactive tasks do not begin to execute as soon as they are assigned. They monitor events in a simulation and execute in response to conditions specified in the script. In this way they are similar to collision avoidance, which takes over entity movement in response to an imminent collision, or trigger statements in plans, which get triggered when a condition becomes true.

      Because reactive tasks are scripted tasks, you are not restricted to the few conditions available in plans. You have the full VR-Forces Lua API available to script the condi- tions and the resulting behaviors. Like other scripted tasks, reactive tasks are either scenario-specific or system reactive tasks.


      Reactive tasks have the following behaviors and characteristics:

      • Reactive tasks can be automatically enabled for a category of simulation object. They can also be individually enabled and disabled.

      • When a reactive task is activated, the current task is suspended. When the reactive task concludes, the simulation object resumes the previous task, if possible. There may be cases where the previous task is no longer meaningful due to changes in the scenario.

      • Reactive tasks support task concurrency.

      • Reactive tasks can be interrupted by other reactive tasks. Precedence among reactive tasks is based on a task’s priority. If a reactive task is executing and a reactive task with a higher priority gets triggered, it suspends the current reactive task. When the higher priority task completes, the lower priority task resumes. When it completes, the original task resumes. Multiple nesting of tasks in this way is permitted. Reac- tive tasks with the same or lower priority do not interrupt the active task.

      • Reactive tasks can have parameters, just like any other task. If a reactive task is enabled and the parameters are not set, it may not work as expected. A well-written reactive task should have default values for parameters, but VR-Forces does not enforce this.

      • Users can change the priority of a reactive task while a scenario is running. This affects the next activation of the task.

      • If a reactive task is interrupted by a non-concurrent independent task assignment, from the Task menu or a global plan, the reactive task and all suspended tasks are canceled and the new task is executed. However, it is still possible that the new task could be interrupted by the same or a different reactive task.

      • Active reactive tasks can be canceled by a VR-Forces user.

      • After a reactive task is complete, it enters the enabled state and can become trig- gered again.

      • The status of a reactive task is displayed on the Task Status page of the Information dialog box, along with the status of the current or suspended task.

      The following sections describe how to manage reactive tasks in a scenario. For infor- mation about how to write and configure reactive tasks, please see Chapter 33, Writing Scripts.


      1. Enabling Reactive Tasks

        Like other scripted tasks, when a reactive task is written, it is specified as being valid for one or more simulation object types. It can also be configured to be enabled by default. If a reactive task is not enabled by default, you can enable it for specific simulation objects.


        image

        i

        i

        This procedure applies to the currently selected simulation object. If you have multiple Information windows open, selecting a reactive task on the Task Status page of a simulation object does not select the simulation object and does not make it the task affected by this procedure.


        image


        To enable a reactive task:

        1. Select the simulation object for which you want to enable the task.

        2. Choose Set Reactive Tasks Enable. The Enable Reactive Task dialog box opens (Figure 26-5). If there are no reactive tasks available, the dialog box states this. This condition occurs if all appropriate reactive tasks are already enabled or there are no reactive tasks for this entity type.


          image

          Figure 26-5. Enable Reactive Task dialog box

        3. In the Reactive Tasks list, select the task you want to enable. If the task requires parameters, the dialog box redisplays and lists the parameters.

        4. If necessary, specify the parameters.

        5. Click OK.


          image

          i

          i

          You can also enable reactive tasks in the Manage Reactive Tasks dialog box. For details, please see “Managing Reactive Tasks,” on page 26-17.


          image


      2. Disabling Reactive Tasks

        You can disable reactive tasks on a per-simulation object basis. When you disable a reac- tive task, any active tasks continue to execute. However, no new instances of the disabled task will be activated.


        image

        i

        i

        This procedure applies to the currently selected simulation object. If you have multiple Information windows open, selecting a reactive task on the Task Status page of a simulation object does not select the simulation object and does not make it the task affected by this procedure.


        image


        To disable a reactive task for a simulation object:

        1. Select the simulation object for which you want to disable a reactive task.

        2. Choose Set Reactive Tasks Disable. The Disable Reactive Task dialog box opens. If there are no reactive tasks available, the dialog box states this. This condi- tion occurs if all appropriate reactive tasks are already disabled or there are no reac- tive tasks for this simulation object type.

        3. In the Reactive Tasks list, select the task you want to disable.

        4. Click OK.


          image

          i

          i

          You can also disable reactive tasks in the Manage Reactive Tasks dialog box. For details, please see “Managing Reactive Tasks,” on page 26-17.


          image


      3. Setting the Priority of a Reactive Task

        When a reactive task is created, it is assigned a priority. The priority determines which reactive tasks it can override or be overridden by. Priorities are expressed as integers, with 1 being the highest priority. You can change the priority of a reactive task on a per- simulation object basis.


        image

        i

        i

        This procedure applies to the currently selected simulation object. If you have multiple Information windows open, selecting a reactive task on the Task Status page of a simulation object does not select the simulation object and does not make it the task affected by this procedure.


        image


        To change the priority of a reactive task:

        1. Select the simulation object for which you want to change a reactive task’s priority.

        2. Choose Set Reactive Tasks Priority. The Reactive Task Priority dialog box opens. If there are no reactive tasks available, the dialog box states this.

        3. In the Reactive Tasks list, select the task whose priority you want to change.

        4. Select a priority in the box. The lower the number, the higher its priority.

        5. Click OK.


          image

          i

          i

          You can also change priority in the Manage Reactive Tasks dialog box. For details, please see “Managing Reactive Tasks,” on page 26-17.


          image


      4. Managing Reactive Tasks

        You can enable, disable, and change priority for all the reactive tasks that apply to a simulation object from the Manage Reactive Task dialog box.

        To manage multiple reactive tasks for a simulation object:

        1. Select the simulation object for which you want to manage reactive tasks.

        2. Choose Set Reactive Tasks Manage or choose Objects Manage Reactive Tasks. The Manage Reactive Task dialog box opens (Figure 26-6). It lists each reac- tive task configured for this simulation object type, its status, and its priority. If a task requires parameters, you can set them.


          image

          Figure 26-6. Manage Reactive Task dialog box

        3. For each task, to enable or disable, select an option from the list in the Enabled column.

        4. For each task, change the priority by selecting an option in the box in the Priority column.

        5. For each task that has parameters, click Parameters and set its parameters. (A task must be enabled to set its parameters.)

        6. Click OK.


      5. Canceling a Reactive Task

You can cancel a reactive task while it is executing. When you cancel a reactive task, the simulation object resumes the suspended task. However, if the condition that caused the reactive task to activate is still true, when you cancel a reactive task, it will usually immediately activate again.


image

i You can also use this procedure to cancel (skip) a regular task.

image

To cancel a reactive task:

  1. Select the simulation object whose task you want to cancel.

  2. Choose Objects Information, or press i. The Information dialog box opens.

  3. Select the Task Status page. If a reactive task is active, it has a button in the Cancel column (Figure 26-7).


    image

    Figure 26-7. Active reactive task

  4. Right-click the active task and choose Cancel Reactive Task, or click the button in the Cancel column.


    1. Using Behavior Sets to Manage Scripts

      Behavior Sets let you organize scripts so that a set of related tasks and set data requests can be enabled or disabled at the force level.

      If a script is not assigned to a Behavior Set, its availability to a simulation object is determined by the following settings:

      • The Valid for Entity Types list for the script.

      • For tasks specific to systems, configuration of that system on a simulation object.

      • For reactive tasks, the Enable/Disable setting in the Manage Reactive Tasks dialog box for the simulation object.

        If a script is assigned to a Behavior Set, then in addition to the requirements in the previous list, it is available to simulation objects only if the Behavior Set is assigned to a force and only to simulation objects of that force. (You can assign a Behavior Set to more than one force.)

        As an example of how you might use Behavior Sets, suppose that dismounted infantry react differently to an attack depending on whether they are operating in rural terrain or in urban terrain. You have a set of scripted tasks that you have written for reacting to attack in each of these two situations. If you are not using Behavior Sets, then to manage which tasks would get used when the simulation objects are under attack, you might use one of the following strategies:

      • Tell users not to use the inappropriate tasks.

      • Enable and disable the correct set of tasks in the Scripts dialog box before the start of the scenario.

      • Enable and disable the tasks on a per simulation object basis in the Manage Reac- tive Tasks dialog box.

Shifting back and forth between simulations in different terrains might become a management problem.

Using Behavior Sets, you could:

  1. Create a Behavior Set for rural terrain operations and one for urban operations.

  2. Assign the relevant scripts to each Behavior Set.

  3. Before you run a scenario, you would assign the Behavior Set you want to use to the force.

The tasks in the Behavior Set would be enabled and those in the unused Behavior Set would be disabled. There would be no further configuration required.

Assigning Tasks — Using Behavior Sets to Manage Scripts

image

      1. Creating Behavior Sets

        To create a Behavior Set:

        1. Choose Simulation Behavior Sets. The Edit Behavior Sets dialog box opens (Figure 26-8).


          image

          Figure 26-8. Edit Behavior Sets dialog box

          image

        2. Click the Add button ( ). The New Behavior Set Name dialog box opens.

        3. Type a name for the Behavior Set.

        4. Click OK.

        5. In the Scripts list, select the scripts that you want to assign to this Behavior Set. Click the left-facing arrow. The scripts are added to the Behavior Set. If you select a folder, all tasks in the folder get added to the Behavior Set. (You can also assign tasks to Behavior Sets in the Edit Script dialog box. For details, please see “Creating a New Script,” on page 32-6.)

        6. Optionally, assign the Behavior Set to a force.


      2. Editing Behavior Sets

        You can edit Behavior Sets, rename them, and delete them.

        To edit Behavior Sets:

        1. Choose Simulation Behavior Sets. The Edit Behavior Sets dialog box opens (Figure 26-8).

        2. Expand the Behavior Set that you want to edit.

        3. Add and remove scripts by selecting them and clicking the appropriate arrow button.

          image

          To rename a Behavior Set, select it in the Behavior Sets list, click the Rename button ( ), and type a new name.

          image

          To delete a Behavior Set, select it in the Behavior Sets list and click the Delete button ( ).


      3. Assigning a Behavior Set to a Force

        You can only assign one Behavior Set to a force at any given time.

        To assign a Behavior Set to a force:

        1. Choose Simulation Behavior Sets. The Edit Behavior Sets dialog box opens (Figure 26-8).

        2. In the Assign Behavior Set to Force window, click the list for the force to which you want to assign a Behavior Set.

        3. Select the Behavior Set that you want to assign. If you do not want any Behavior Sets assigned, select the blank line in the list.

Assigning Tasks — Entity Movement On Roads and Off Roads

image

    1. Entity Movement On Roads and Off Roads

      Some terrains have vector road networks. Ground vehicles can use these networks to move precisely through the terrain. The tasks for moving on roads are distinct from the tasks for moving without respect to road networks. (For a description of how entities move when they use road driving, please see “Road Driving Behavior,” on page 26-23.) If you want entities to move both on and off roads, you need to understand how these tasks interact.

      The road driving tasks are Move to Waypoint (Plan Along Roads) and Move to Loca- tion (Plan Along Roads). The generic movement tasks are Move to Location and Move to Waypoint.


      image

      !

      !

      Road driving tasks are valid only for ground vehicles. If you give a road driving task (including Move To (Plan Along Roads), Treat Route as Road, and Use Roads in pattern of life default plans) to any other type of entity, it will fail.


      image


      When you give a simulation object a generic Move To task, it moves directly towards its destination. If navigation data is available, it plans a path using that data. If no naviga- tion data is available, the entity avoids obstacles, but otherwise does not pay attention to the terrain except to the extent that it cannot move on certain soil types or terrains that are too steep.

      When you give an entity a Plan Along Roads task, it looks for a road network. If it finds one:

      • It moves to the nearest point on the road.

      • It moves along the road network to the nearest point to the final destination.

      • It moves to the final destination.


image

i

i

The road driving feature in VR-Forces requires that the road vectors making the network be connected at their edges. If your terrain’s data does not have accurate positions for road ends, which causes them to be disconnected, VR- Forces may not be able to plan a path along those roads.


image


      1. Road Driving Behavior

        The Move To (Plan Along Roads) tasks use road driving behaviors intended to provide realistic behavior of multiple cars on a road network. When an entity is given one of these tasks:

        • It clamps to the road and does not deviate from it.

        • It goes around corners accurately.

        • It ignores any obstacles that are near to the road and which would ordinarily trigger obstacle avoidance. The vehicle only responds to obstacles that block the road.

        • If a vehicle is blocking its progress and there is an adjacent lane in the road that is clear, the entity passes the blocking vehicle.

In the Move Along Route task, you can specify that VR-Forces treat the route as a road. The entity would then use the road driving system to follow the route.


    1. Fixed-Wing Entity Tasks and Behaviors

      This section describes the behaviors of fixed-wing entities supplied with VR-Forces and the issues you should keep in mind when assigning tasks and set data requests.


      1. Placement of Newly Created Fixed-Wing Entities

        When you create a fixed-wing entity, it is placed on the ground. If you want a fixed- wing entity to start a scenario in the air, you must set its altitude at the beginning of the scenario. It will loiter at the specified altitude.


        image

      2. Fly Task Behavior is Different from Move Task Behavior

        Fixed-wing entities can move in response to Fly tasks (Fly Altitude, Fly Heading, and so on) and Move tasks (Move to Waypoint, Move Along Route, and so on). There are important differences between how fixed-wing entities respond to the different classes of movement tasks. Fixed-wing entities can move on the ground (taxi), in which case they move like ground vehicles.

        For Move and Patrol tasks, if a fixed-wing entity is in the air:

      3. Specifying and Maintaining Altitude for Fixed-Wing Entities

        You can explicitly change a fixed-wing entity’s altitude in the following ways:

        • The Altitude set data request moves an entity immediately to the specified altitude.

        • The Move to Altitude task causes an entity to spiral to the specified altitude at the same coordinates that it had when it received the task.

        • The Fly Altitude and Fly Heading and Altitude tasks cause the entity to move smoothly to the new altitude while continuing to fly at its current or newly speci- fied heading.

          An entity’s altitude changes implicitly if it is given a Move or Patrol task in which the altitude of the target point or vertex is different from the entity’s current altitude. In this case the entity immediately moves to the new altitude and then proceeds to the target point.


          image

          i

          i

          When you assign a task that includes a location and you specify the location by clicking on the terrain, the default altitude is zero. If you do not specify a non-zero altitude in the task dialog box, VR-Forces uses the altitude of the entity at the time the task is assigned. This prevents you from inadvertently specifying a location that would cause the entity to crash.


          image


      4. Fixed-Wing Entity Movement on the Ground and in the Air

        Fixed-wing aircraft support takeoff and landing. Since they can move on the ground and in the air, you need to understand their behavior in these different environments. Table 26-1 and Table 26-2 describe how fixed-wing entities respond to Move To, Move Along Route, and Patrol Route tasks depending on their current location. The rest of this section provides additional details about take-off and landing.


        Table 26-1: Fixed-wing entity Move To behavior

        If entity is on/in the:

        and waypoint is on/in the:

        the entity:

        Ground

        Ground

        taxis to point.

        Ground

        Air

        takes off towards the point.

        Air

        Air

        flies to point.

        Air

        Ground

        crashes.


        Table 26-2: Fixed-wing entity route-following behavior

        If entity is on/in the:

        and next vertex is on/in the:

        the entity:

        Ground

        Ground

        taxis to vertex.

        Ground

        Air

        takes off toward the vertex.

        Air

        Air

        flies to the vertex.

        Air

        Ground

        tries to land at the vertex.


        Fixed-wing entities do not support terrain-following. Therefore, when you task a fixed- wing entity to move to a point or follow a route, you must be certain that there are no points in the terrain that are higher than the altitude of the entity’s flight path, or the entity will crash. For example, if you assign a fixed-wing entity to follow a route whose vertices are set at 3000 meters above sea level, if the terrain rises above 3000 meters at some point in between two vertices of the route, the entity will crash into the terrain at that point (Figure 26-9). You can view the terrain profile of the route to check for inter- sections with the terrain. (For details, please see “Displaying a Line’s Terrain Profile,” on page 54-3.)


        image

        Trajectory

        Route


        Figure 26-9. Fixed-wing route following


        Fixed-Wing Movement Between Vertices

        If two vertices in a route are not at the same altitude, a fixed-wing entity does not fly from the first vertex to the second in a smooth gradient. As soon as it passes the first vertex, it immediately descends to the altitude of the next vertex and then continues to fly towards it at that altitude. Therefore, it is possible that you could create a route that does not intersect the terrain, but an entity flying along that route could crash because a location in the terrain exceeds the altitude of a destination point, as illustrated in Figure 26-10.


        image

        Route



        Intended Flight path

        Terrain profile


        Figure 26-10. Fixed-wing trajectory between vertices


        image

        i

        i

        If you want a plane to change altitude using a smooth gradient, use one of the Fly Altitude tasks. However, these tasks do not let you follow a route.


        image


      5. How Fixed-Wing Entities Take Off

        You can have fixed-wing aircraft take off using the Fixed Wing Takeoff task (for details, please see “Fixed Wing Takeoff,” on page 27-8) or by using innate behavior. This section describes take-off using innate behavior.

        Fixed-wing entities take off by moving to a waypoint that is above ground level or by following a route that has a vertex above ground level.

        When you task a fixed-wing entity to move to a waypoint that is above ground level, the entity orients itself directly towards that point and accelerates in the direction of the point. When it reaches its minimum lift speed, it takes off and rises to the altitude of the point it is moving to. You can control the distance required to take off by setting the max-thrust parameter.

        When a fixed-wing entity takes off, it does not take into account the soil type or terrain, except that if the slope of the terrain along which the entity must move to take off is greater than the max-slope parameter, the entity halts.

        Fixed-wing entities do not know anything about runways that may be part of a terrain database. When you create a waypoint towards which an entity will take off, or create a route along which an entity will take off, you are responsible for ensuring that the entity is properly oriented towards the runway.

        If an entity takes off as part of route following, you can define a runway with two points on the ground. If an entity detects that the point in the route after the one it is moving towards is in the air, it uses the current point as the take-off direction, but takes off as soon as possible and flies to the point in the air. Figure 26-11 illustrates this behavior.


        image

        Vertex determines take-off heading (Z= 0 m) Z=1000 m



        Heading after take-off

        Heading during take-off

        Take-off point

        Figure 26-11. Defining a runway for take-off


        image

      6. How Fixed-Wing Entities Land

        You can have aircraft land using the Fixed Wing Land task (please see “Fixed-Wing Land,” on page 27-7), or as described in this section. The underlying behavior of the Fixed Wing Land task is the same as in this section. Using the Fixed Wing Land task automates the process of setting up the approach route.

        A fixed-wing entity can land only in the context of following or patrolling a route. When a fixed-wing entity follows a route and determines that the next vertex in the route is on the ground, it decelerates as it reduces altitude towards that vertex. If it does not have enough distance from the previous vertex to decelerate sufficiently, it may crash. To ensure adequate deceleration, you may want to create a trigger that sets the entity’s speed when it approaches the runway.


        image

        i

        i

        Any time an entity is within 10 meters of the terrain and it is moving within 10 percent of its minimum lift speed, it will try to land.


        image


        To orient an entity for landing, you may have to create several vertices prior to the runway to get the entity properly lined up. Figure 26-11 shows two different routes ending at an airport (the routes have been edited to improve visibility). The first route has vertices that line up the entity with the runway. The second route curves in towards the runway, so the entity does not approach the runway in a straight line. Therefore, as it reaches the landing point, it is not lined up with the runway and it lands on the taxiway.

        Assigning Tasks — Rotary-Wing Entity Tasks and Behaviors

        image


        image image

        image

        image

        Entity lands on runway


        Entity lands to left of runway


        Figure 26-12. Landing fixed-wing entities


        image

    2. Rotary-Wing Entity Tasks and Behaviors

      This section describes the behaviors of rotary-wing entities supplied with VR-Forces and the issues you should keep in mind when assigning tasks and set data requests.

      Rotary-wing entities get created on the ground unless you specify an altitude at creation. (For details about specifying an altitude when you create an air platform, please see “Specifying an Object’s Altitude,” on page 16-14.)

      If a rotary-wing entity is airborne and it is not assigned a task, it hovers at the specified location and altitude. When it completes a task, it hovers in the location where it completed the task.

      Assigning Tasks — Rotary-Wing Entity Tasks and Behaviors

      image


      The terrain-check parameter determines how a rotary-wing entity interacts with the terrain. If terrain-check is False, a rotary-wing entity ignores the terrain. It could appear to fly below ground. However, when terrain-check is set to False, VR-Forces does not have to check ground points, so performance may improve.

      When terrain-check is True, rotary-wing entities interact with the terrain. If a rotary- wing entity approaches a ground point at three meters per second or less, it lands. If it approaches the ground at a greater speed, it crashes.


      image

      i

      i

      • When you assign a task that includes a location and you specify the loca- tion by clicking on the terrain, the default altitude is zero. If you do not specify a non-zero altitude in the task dialog box, VR-Forces uses the alti- tude of the entity at the time the task is assigned. This prevents you from inadvertently specifying a location that would cause the entity to crash.

      • Rotary-wing entities are not able to reach moving waypoints or land on moving ships. A rotary-wing entity will approach a given waypoint or landing point, but will never completely reach the goal.


      image


      Helicopters have a basic terrain avoidance algorithm that helps prevent crashing if they are sent to waypoints or follow routes that do not have an altitude. The terrain avoid- ance logic maintains a distance above the ground; it does not look ahead. So, a heli- copter could crash if the terrain rises suddenly (Figure 26-13). You can view the terrain profile of the route to check for intersections with the terrain. (For details, please see “Displaying a Line’s Terrain Profile,” on page 54-3.)

      Rotary-wing aircraft take wind resistance and the weight of the aircraft, including the weight of any embarked objects, into account when calculating fuel consumption.



      image


      Figure 26-13. Helicopter terrain avoidance


      image

      1. Controlling Rotary-Wing Orientation

        A rotary-wing entity can move laterally (sideways) without changing its orientation. In other words, it does not have to face in the direction it is moving. Rotary-wing entity movement controllers have two parameters that configure the speed at which a rotary- wing entity can move laterally. Rotary-wing entities rotate to try to align themselves with their velocity vector under the following circumstances:

If you do not want a rotary-wing entity to align itself with its direction of travel, set vel- to-align-actual and vel-to-align-desired to speeds that are greater than the speed at which you expect the entity to travel. You can set these parameters in the OPD Editor.


    1. Suppressive Fire Tasks

      VR-Forces has two suppressive fire tasks.

The Lifeform Suppression system enables two reactive behaviors. The first one makes the human adopt a crouching posture when it is suppressed. This does not interrupt other movement. The second reaction makes the entity go prone when it is suppressed to level 2 or 3. This interrupts any ongoing movement task. Both reactions restore the original posture when the reaction ends.

Several vehicles are configured so that they cannot fire their machine guns if they are suppressed.

An entity is susceptible to suppression if it has a suppression system. Lifeforms can have a Lifeform Suppression system. Vehicles can have a Vehicle Exposed Crew Suppression system. For details about configuring suppression, please see “Configuring Suppression Effects,” on page 26-34.


      1. Configuring Suppression Effects

        Suppression effects are configured by parameters in several components.

        The suppression system contains a suppression actuator with several parameters to control its behavior.

        • suppression-insult-level. The level of insult necessary to suppress the entity, that is, reach the level 1 threshold. This value should be set appropriately for the amount of insult caused by munitions, as defined in the damage-model portion of this descriptor. You can set this parameter in the Simulation Object Editor.

        • suppression-recovery-time. The time required to recover from the level 1 suppression threshold to a not-suppressed state. This same time is required to recover to level 2 from level 3, and to level 1 from level 2. You can set this parameter in the Simula- tion Object Editor.

        • passing-rounds-suppress. Determines whether rounds passing by the entity, but not necessarily detonating near it, are considered when detecting insults. You can turn off this effect to save computation time. Default: true.

        • max-detonation-distance-for-passing-rounds. The maximum distance that the actuator looks for detonations. A line of fire that passes near the entity may detonate some distance beyond the entity. To find such lines, the actuator must look at distant detonations. This may result in the actuator processing many detonations. (The detonation manager makes a distance test for each entity for each detonation, so not much computation is saved by reducing this parameter value.)

        • hostile-fire-only. If true, the actuator does not consider detonations and passing rounds as insults if they are from a friendly force. Default: true. While the default may be unrealistic in the case of HE shells landing near the entity, it avoids unin- tended suppression when nearby friendly entities are firing at the enemy.

          The actuator descriptor includes a damage-model section that is just like the damage- model in a damage system. For each munition there are two parameters:

        • suppression-detonation-insult. The maximum insult that this munition can cause, if it detonates at the entity location or passed directly over the entity.

        • suppression-detonation-range. The maximum range at which the munition can have effect. The insult from the munition decreases linearly until it is 0 at the maximum range.

In ballistic gun controllers, disabled-by-suppression indicates whether the gun is suscep- tible to suppression. If true, the gun is not allowed to fire while the entity is suppressed. This is true for the handheld weapon systems, but it can also be selectively set for guns on vehicles. For example, tank machine guns are often operated by an exposed crew member, and could be suppressed by small arms fire even if the tank is otherwise unaf- fected by such fire. The handheld systems have this parameter set True, while other machine guns use a variable and so the parameter can be set in the Simulation Object Editor.

Assigning Tasks — Configuring Task Execution Rules

image


In sensor components, suppression-degrades-sensor-performance-by indicates how they are affected by suppression. It is a value from 0 - 1.0. A value of 0 means that the sensor is not degraded at all by suppression, while a value of 1.0 means that sensitivity is reduced to 0 by suppression. The value can be set in the Simulation Object Editor.


    1. Configuring Task Execution Rules

      Each simulation object OPE file contains a parameter called task-execution-rules that specifies a task execution rule configuration file. (The default rules file is ./data/simula- tionModelSets/<model_set>/vrfSim/taskRules/default-task-rules.tsk.) The task execution rule file specifies whether or not tasks can be executed concurrently, and if so, which tasks are mutually exclusive.

      The task execution rules file has the following parameters:

      • all-tasks-exclusive. This parameter enables (False) or disables (True) use of concur- rent execution of tasks. When True, the Task Manager executes only one task at a time, and the mutually-exclusive-task-groups parameter is ignored.

      • mutually-exclusive-task-groups. This parameter is a list of groups. Each group contains a list of tasks that cannot be executed at the same time. Any time a task from a particular group is started by the Task Manager, any currently running task that is part of the same group is interrupted. Tasks that are part of other groups, or not part of any group, are allowed to continue running.

The task names that are listed in the mutually-exclusive-task-groups parameter are the names that are registered with the task factory when a task is added to the system. Groups can contain any number of tasks, and there can be any number of groups.

Tasks are always considered to be mutually exclusive with themselves. For that reason, it is impossible to execute two tasks of the same type at the same time on a single simula- tion object.


image

i

i

default-task-rules.tsk configures the tasks that come with VR-Forces and which were developed in C++. It does not include scripted tasks.

Concurrency for scripted tasks gets set when they are created.


image

Assigning Tasks — Configuring Task Execution Rules

image

26.9.1. Configuring Action Categories

In scripted tasks, action categories serve the same function as task rules for enforcing concurrency. Action categories are configured in ./data/simulationModel- Sets/<model_set>/vrfSim/taskRules/actionCategories.tsk. An action category is specified with the following entry:

<item>

<first>Movement</first>

<second>

<first>Movement</first>

<second>1</second>

</second>

</item>

If the value in the <first> element matches a group in ./data/simulationModel- Sets/<model_set>/vrfSim/taskRules/default-task-rules.tsk, scripted tasks that use that action category are unioned with the tasks specified in default-task-rules.tsk to form the complete set of mutually exclusive tasks.


image

i

i

If you edit actionCategories.tsk, be sure to update the <count> element to reflect additions or deletions.


image


image

27. Movement Tasks for Entity-Level Scenarios


This chapter describes the movement tasks supplied with VR-Forces that apply to entity-level scenarios. Some of these tasks are also used in aggregate-level scenarios. Chapter 29, Human and Crowd Tasks describes some movement tasks that are specific to human characters.

Animated Movement 27-3

Come to Stop 27-4

Convoy Along 27-4

Convoy To 27-5

Fast Rope Insertion 27-6

Fixed-Wing Land 27-7

Fixed Wing Takeoff 27-8

Fly Altitude 27-8

Fly Heading 27-9

Fly Heading and Altitude 27-10

Follow Entity 27-11

How Fixed-Wing Entities Follow Entities 27-11

Generate Air Traffic From Flight Plans 27-12

Land at Airport Near Location 27-12

Move Along Route 27-13

Move Into Formation 27-14

Move to Altitude 27-15

Move to Depth 27-15

Move to Location 27-16

Adding Multiple Move to Location Tasks to a Plan 27-17

image

Movement Tasks for Entity-Level Scenarios

Move to Location (Plan Along Roads) 27-18

Move to Location (Plan Path) 27-19

Move to Waypoint 27-20

Move to Waypoint (Plan Along Roads) 27-21

Move to Waypoint (Plan Path) 27-22

Orbit 27-23

Patrol Route 27-23

Patrol Between 27-24

Pattern Hold (Location) 27-24

Pattern Hold (Waypoint) 27-25

Rotary Wing Airlift Cargo to Location 27-25

Rotary Wing Land 27-26

Rotary Wing Retrieve Cargo 27-26

Rotary Wing Unload Cargo 27-27

Sail Heading 27-27

Turn to Heading 27-28

Movement Tasks for Entity-Level Scenarios — Animated Movement

image

    1. Animated Movement

      The Animated Movement task lets you assign a scripted behavior to an entity. This task is a generalized version of firing ballistic missiles, which is described in “Ballistic Missiles,” on page 10-8. To use this task, you must first create a file that describes the movements that you want an entity to make. Animated movement files can be in comma-separated values (CSV) format or 3DS ASCII Export (ASE) format. You configure animated movement tasks in the Simulation Object Editor. For details, please see “Configuring Animated Movement,” on page 65-50.

      To assign an animated movement task:

      1. Select the entity to task.

      2. Choose Task Movement Animated Movement. The Animated Movement dialog box opens (Figure 27-1).


        image

        Figure 27-1. Animated Movement dialog box

      3. Optionally, filter the animation list by selecting a category in the Category list.

      4. Select an animation in the Animation list. You are responsible for knowing that the animation is appropriate to the entity you selected.

      5. Optionally, specify a time scale. By changing the time scale you can make the animation run faster or slower than specified in the animation file.

      6. Click OK.

        Movement Tasks for Entity-Level Scenarios — Come to Stop

        image

    2. Come to Stop

      The Come to Stop task stops a surface entity using a normal stop, an emergency stop, or a slow drift.

      To assign a Come to Stop task:

      1. Select the entity.

      2. Choose Task Movement Come to Stop. The Come to Stop dialog box opens.

      3. Select an option for how to stop.

      4. Click OK.


    3. Convoy Along

      The Convoy Along task commands a unit to move along a route in a convoy. When the task starts, the lead entity moves far enough along the route for the rest of the unit to create a column that ends approximately at the beginning of the route. Then the unit begins moving along the route.


      image

      i The Convoy Along task is valid only for ground-vehicle aggregates.

      image

      For more details about convoys, please see “Convoy Tasks,” on page 26-11.

      To assign a Convoy Along task:

      1. Select the unit that you want to send in a convoy.

      2. Choose Task Movement Convoy Along. The Convoy Along dialog box opens.

      3. Specify the route to convoy along.

      4. Click OK.


      image

    4. Convoy To

      Movement Tasks for Entity-Level Scenarios — Convoy To

      The Convoy To task commands a unit to move to a waypoint in a convoy. If you specify use of roads, VR-Forces uses the information in the road network to plan the convoy’s movement. If you do not specify use of roads, the convoy moves directly across the terrain as an individual entity would move in a Move To task.


      image

      i The Convoy To task is valid only for ground-vehicle aggregates.

      image

      For more details about convoys, please see “Convoy Tasks,” on page 26-11.

      To assign a Convoy To task:

      1. Select the unit that you want to send in a convoy.

      2. Choose Task Movement Convoy To. The Convoy To dialog box opens.

      3. Specify the waypoint to convoy to.


        image

        !

        !

        When you specify use of roads, VR-Forces looks for roads over a fairly wide area and if one is found, will try to use them even if this results in an indirect approach to the waypoint. If there are no roads close to the route you would expect the unit to take to reach the waypoint, do not select this option.


        image


      4. Click OK.

      Movement Tasks for Entity-Level Scenarios — Fast Rope Insertion

      image

    5. Fast Rope Insertion

      The Fast Rope Insertion task causes a helicopter to move to a specified waypoint and disembark a specified number of embarked humans using a fast rope animation. The disembarked humans slide down the rope, then move to a specified muster point and assume a kneeling posture.

      This task is available only to helicopters that have the Fast Roping system, such as the MH-60 Black Hawk.

      To assign a Fast Rope Insertion task:

      1. Embark human entities on a helicopter that supports the Fast Rope Insertion task.

      2. Select the helicopter.

      3. Choose Task Movement Fast Rope Insertion. The Fast Rope Insertion dialog box opens.

      4. Specify the waypoint at which the insertion should take place.

      5. Specify the altitude at which the helicopter should hover.

      6. Specify the number of humans to be disembarked and inserted.

      7. Specify the waypoint the humans should go to after disembarking.

      8. Click OK.

        Movement Tasks for Entity-Level Scenarios — Fixed-Wing Land

        image

    6. Fixed-Wing Land

      “How Fixed-Wing Entities Land,” on page 26-29, describes how fixed-wing entities land and the steps to design a landing approach. The Fixed Wing Land task automates the process of landing a fixed-wing aircraft. However, you must still specify a route to serve as the runway.

      When the task is invoked, VR-Forces defines an approach route for the plane to move along. The length of this route is either the plane’s altitude or the length needed to slow the plane down to landing speed, whichever is greater. The route is created and the plane moves along the route, coming to landing speed. At the end of the approach route, the plane is tasked to move along the runway.


      image

      !

      !

      Although it is possible to land an entity on another entity, such as an aircraft carrier, if you want to embark an entity, you must use the Embark task, not a landing task.


      image


      To land a fixed-wing aircraft:

      1. Select the entity.

      2. Choose Task Movement Fixed Wing Land. The Fixed Wing Land dialog box opens.

      3. In the Name box, type the name of the route you want it to land on, or select the route in the list or on the terrain.

      4. Click OK.

        Movement Tasks for Entity-Level Scenarios — Fixed Wing Takeoff

        image

    7. Fixed Wing Takeoff

      You can explicitly task a fixed-wing entity to take off. (For details about implicit take- off, please see “How Fixed-Wing Entities Take Off,” on page 26-28.) In a Fixed Wing Takeoff task, the entity moves along the specified route, reaches takeoff speed (30% of minimum lift), and then moves to a point defined by the controller some distance up and away from the end of the route.

      To assign a Fixed Wing Takeoff task:

      1. Select the entity.

      2. Choose Task Movement Fixed Wing Takeoff. The Fixed Wing Takeoff dialog box opens.

      3. Select the route to take off on or type its name in the Name box.

      4. Click OK.


    8. Fly Altitude

      The Fly Altitude task commands a fixed-wing or rotary-wing entity to fly to the speci- fied altitude at a specified ascent or descent rate, using its current heading and ordered speed. When it reaches the altitude it continues to fly at that altitude at the current heading until it receives other commands. The entity will not exceed the limits for alti- tude or ascent/descent rate set in the OPD for the entity type.

      You cannot use a Fly Altitude task to cause a fixed-wing entity to take off. A fixed-wing entity that is on the ground ignores this task.

      If a rotary-wing entity is on the ground and is given this task, it rises to the specified altitude as it moves forward at its current heading. If a rotary-wing entity is in the air and is given this task with an altitude of zero, it descends to approximately 33 M and continues flying at that altitude at its current heading.

      To assign a Fly Altitude task:

      1. Select a fixed-wing or rotary-wing entity.

        image

      2. Choose Task Movement Fly Altitude, or click the Fly Altitude button ( ) on the Last Selected Object Panel or the Tasks Toolbar. The Fly Altitude dialog box opens.

      3. In the Altitude box, specify the altitude above sea level to fly to.

      4. In the Climb/Descent Rate box, specify the rate.

      5. Click OK.


        image

    9. Fly Heading

      Movement Tasks for Entity-Level Scenarios — Fly Heading

      The Fly Heading task commands a fixed-wing or rotary-wing entity to turn to the spec- ified heading at the specified turn rate. It maintains its current altitude and speed.

      When it is finished turning to the new heading, it continues to fly at this heading until it receives other commands. The entity will not exceed the turn rate specified in the OPD.

      A fixed-wing entity that is on the ground ignores this task.

      If a rotary-wing entity is on the ground and is given this task, it rises to approximately 60 M and then drops down to approximately 33 M while simultaneously moving forward and turning to the specified heading. After turning to the new heading, it continues moving forward. Its altitude varies somewhat as it follows the terrain.

      To assign a Fly Heading task:

      1. Select a fixed-wing or rotary-wing entity.

        image

      2. Choose Task Movement Fly Heading, or click the Fly Heading button ( ) on the Last Selected Object Panel or the Tasks Toolbar. The Fly Heading dialog box opens.

      3. In the Heading box, specify the heading to fly to.

      4. In the Turn Rate box, specify the rate.

      5. Click OK.

        Movement Tasks for Entity-Level Scenarios — Fly Heading and Altitude

        image

    10. Fly Heading and Altitude

      The Fly Heading and Altitude task commands a fixed-wing or rotary-wing entity to fly to a specified altitude, at a specified ascent or descent rate, while turning to a specified heading at a specified turn rate. If you do not specify a heading or altitude, the entity continues to use the current value for that parameter.

      While executing this task, the entity maintains its current speed. When it completes the command, it continues to fly at the new altitude and heading until given other commands. The entity will not exceed the limits on altitude, turn rate, and ascent/descent rate set in the OPD.

      You cannot use a Fly Heading and Altitude task to cause a fixed-wing entity to take off. A fixed-wing entity that is on the ground ignores this task.

      If a rotary-wing entity is on the ground and is given this task, it takes off and moves forward while it rises to the specified altitude and turns to the specified heading. If a rotary-wing entity is in the air and is given this task with an altitude of zero, it moves forward and turns to the new heading while it descends to approximately 33 M and continues flying at that altitude on the new heading.

      To assign a Fly Heading and Altitude task:

      1. Select a fixed-wing or rotary-wing entity.

      2. Choose Task Movement Fly Heading and Altitude, or click the Fly Heading and Altitude button image) on the Last Selected Object Panel or the Tasks Toolbar. The Fly Heading and Altitude dialog box opens.

      3. In the Heading box, specify the heading to fly to.

      4. In the Altitude box, specify the altitude above sea level to fly to.

      5. In the Turn Rate box, specify the rate.

      6. In the Climb/Descent Rate box, specify the rate.

      7. Click OK.


        image

    11. Follow Entity

      Movement Tasks for Entity-Level Scenarios — Follow Entity

      You can order an entity to follow a simulation object. You can specify a distance and offset between the simulation objects. If you tell two or more entities to follow the same simulation object, make sure that you do not give them the same offset (please see “Following Simulation Objects,” on page 35-18).

      An entity continues to follow its target entity until:

      • The task is overridden.

      • The followed entity is destroyed.

      If entity A is assigned to follow entity B, but it cannot find entity B, entity A continues to look for entity B until entity B becomes available, or until entity A is assigned another task.

      The following entity tries to match the speed of the followed entity unless it has to hold back or catch up to accommodate changes in direction or terrain effects.

      To order an entity to follow a simulation object:

      1. Select the entity.

      2. Choose Task Movement Follow Entity. The Follow Entity dialog box opens.

      3. Optionally, filter the entity list.

      4. In the Name box, type the name of the entity to follow, or select it from the list or on the terrain.

      5. Optionally, type an offset in the Behind, Right, and Above text boxes. If you want an entity to follow in front, to the left, or below, put a minus sign (-) in front of the value.

      6. Click OK.


        27.11.1. How Fixed-Wing Entities Follow Entities

        A fixed-wing entity can follow an entity that is on the ground, or might be on the ground, for example if it is following a fixed-wing entity that lands. To ensure that the follower does not crash, make sure that it is following above the followed entity and that the distance above is high enough to account for changes in the terrain.

        Movement Tasks for Entity-Level Scenarios — Generate Air Traffic From Flight Plans

        image

    12. Generate Air Traffic From Flight Plans

      VR-Forces can generate air traffic along routes created using X-Plane format flight plans. It includes several flight plans for flights in the U.S. and between the U.S. and Europe. You can add flight plans by placing them in ./data/flightPlans.

      When you execute this task, VR-Forces generates routes for flight plans that overlap a specified area of interest. If there are no flight plans in the area of interest, an error message is sent to the Information dialog box for the plan.

      To generate air traffic from flight plans:

      1. Create a global plan.

      2. Choose Task Generate Air Traffic From Flight Plans. The Generate Air Traffic from Flight Plans dialog box opens.

      3. In the Maximum Aircraft box, type the maximum number of aircraft you want to have flying at one time. This number only applies to the current task. If you run more than one instance of the task, each task handles the number of aircraft inde- pendently.

      4. To create air traffic along the routes rather than have all the planes start at the beginning of the routes, select the Create Enroute check box.

      5. Select an area of interest. Flight plans that overlap this area get generated.

      6. Click OK.


    13. Land at Airport Near Location

      The Land at Airport Near Location task causes VR-Forces to find an airport near the specified location and land the specified aircraft on an appropriate runway based on the wind direction. This task requires use of a terrain database that has airport and runway data. The ProceduralEarth (online).mtf terrain has airport data.

      To land an aircraft at an airport:

      1. Select the entity.

      2. Choose Task Movement Land at Airport Near Location. The Land At Airport Near Location dialog box opens.

      3. Specify the location in the dialog box or on the terrain.

      4. Click OK.

        Movement Tasks for Entity-Level Scenarios — Move Along Route

        image

    14. Move Along Route

      By default, a simulation object moves along a route from its nearest vertex to its end point.

      To direct a simulation object to move along a route:

      1. Select the simulation object.

      2. Choose Task Movement Move Along Route, or click the Move Along Route button ( image) on the Tasks Toolbar. The Move Along Route dialog box opens.

      3. In the Name box, type the name of the route you want the simulation object to follow, or select a route in the list or on the terrain.

      4. To have the simulation object move from the end of the route to the beginning, select Reverse Direction.

      5. To have a ground vehicle use the road driving movement strategy, select the Treat Route as Road check box. The route is treated as a two-lane bidirectional road.


        image

        !

        !

        If you select Treat Route as Road, the entity must be within 10 meters of the route or the task will fail.


        image

        Movement Tasks for Entity-Level Scenarios — Move Into Formation

        image


      6. To have the simulation object start the route at the beginning, clear the Start at Closest Vertex check box.

      7. Click OK.


    15. Move Into Formation

      You can order a disaggregated ground unit to move to a formation at a specified loca- tion. Moving to a formation is not the same as setting formation. Setting formation changes the formation instantly. Moving to a formation causes the members of the unit to travel through the terrain into the new formation.

      For aggregated units, Move Into Formation has the same effect as a Formation set data request.

      To direct a unit to move to a formation:

      1. Select the unit.

      2. Choose Task Movement Move Into Formation. The Move Into Formation dialog box opens.

      3. Select the desired formation from the list.

      4. Specify the location at which the unit is to move into formation by entering coordi- nates, or by clicking on the terrain.

      5. Specify the heading the unit is to assume at the target location.

      6. Click OK.

        Movement Tasks for Entity-Level Scenarios — Move to Depth

        image

    16. Move to Altitude

      You can order an aircraft entity to move to an altitude. When you assign this task, the entity moves to the new altitude at the same coordinates. Fixed-wing aircraft spiral to the new coordinates. Rotary-wing entities rise or descend. Moving to an altitude is not the same as setting altitude. Setting altitude moves an entity instantaneously. It is also not the same thing as Fly Altitude. At the conclusion of Move to Altitude, an aircraft circles or hovers at the new altitude. At the conclusion of Fly Altitude, an aircraft continues moving at its current heading.


      image

      i

      i

      Fixed-wing entities that are on the ground cannot respond to a Move to Altitude task. If they are given this task, a message is printed to the object console and the task is ignored.


      image


      To send an entity to an altitude:

      1. Select the entity.

      2. Choose Task Movement Move to Altitude, or click the Move to Altitude button ( image) on the Tasks Toolbar. The Move to Altitude dialog box opens.

      3. Type the altitude that you want the entity to move to.

      4. Click OK.


    17. Move to Depth

      The Move to Depth task lets you specify the depth for subsurface entities. When an entity moves to a depth, it continues any horizontal movement that was in effect prior to starting the task.

      To assign a move to depth task:

      1. Select the entity.

      2. Choose Task Movement Move to Depth. The Move to Depth dialog box opens.

      3. Select an option for the depth. If you choose a specific depth, type a depth in the Target Depth box.

      4. Specify the ascent/descent rate.

      5. Click OK.

        Movement Tasks for Entity-Level Scenarios — Move to Location

        image

    18. Move to Location

      You can order a simulation object to move to a location. If navigation data is present, simulation objects take it into account in planning their path to the location.

      If you add Move to Location tasks to a plan, you have more options than when you give an independent task.

      Moving to a location is not the same as setting location. Setting location moves a simu- lation object instantaneously. Moving to a location causes a simulation object to travel through the terrain.

      If you want a simulation object to use the road network to move to a location, use Move to Location (Plan Along Roads). For details about road movement, please see “Entity Movement On Roads and Off Roads,” on page 26-22.

      To direct a simulation object to move to a location:

      1. Select the simulation object.

      2. Choose Task Movement Move to Location, or click the Move to Location button image) on the Tasks Toolbar. The Move to Location dialog box opens.

      3. Click on the terrain where you want the simulation object to move, or enter the coordinates of the location in the Move to Location dialog box.

      4. Optionally, set the altitude, as described in “Specifying an Object’s Altitude,” on page 16-14.


        image

        i

        i

        If you specify the location by clicking and the task is for an air platform that is in the air, be sure to change the altitude to a height that will prevent the entity from crashing.


        image


      5. Click OK.

        Movement Tasks for Entity-Level Scenarios — Move to Location

        image

            1. Adding Multiple Move to Location Tasks to a Plan

              When you add a Move to Location task to a plan, you can add multiple locations without clicking OK and selecting the task again from the menu. Also, since in this method you cannot specify the altitude for each location, you can specify a height above the terrain for the altitude of the succeeding points.

              To add multiple Move to Location tasks to a plan:

              1. In the Plan window for a simulation object, choose Task Movement Move to Location. The Move to Location dialog box opens.

              2. Select Each Click Generates A Task.

              3. If you want to specify an altitude for the locations, specify an altitude, as described in “Specifying an Object’s Altitude,” on page 16-14.

              4. Click a point on the terrain for each location that you want the simulation object to move to. A Move to Location task is added to the plan for each location.

              5. Click OK.

        Movement Tasks for Entity-Level Scenarios — Move to Location (Plan Along Roads)

        image

    19. Move to Location (Plan Along Roads)

      The Move to Location (Plan Along Roads) task directs a ground vehicle to move to a location using roads, if there is a road network.

      When an entity receives this task, it determines if there is a road network near by. If there is, it moves directly to the nearest point on the road network. Then it moves along the roads using road driving behavior until it gets to the point on the road that is closest to the destination. Then the entity moves off the road directly to the destination.

      For more information about road driving and how the path planning tasks work, please see “Entity Movement On Roads and Off Roads,” on page 26-22.

      To move a ground vehicle to a location using roads:

      1. Select the entity.

      2. Choose Task Movement Move to Location (Plan Along Roads). The Move to Location (Plan Along Roads) dialog box opens.

      3. Click on the terrain where you want the entity to move, or enter the coordinates of the location in the dialog box.

      4. Click OK.

        Movement Tasks for Entity-Level Scenarios — Move to Location (Plan Path)

        image

    20. Move to Location (Plan Path)

      The Move to Location (Plan Path) task is for surface and subsurface entities. It plots a route to the destination location based on the depth of water between the starting point and ending point. You specify the minimum depth required for the ship to maneuver. You can specify that the depth be based on the ship’s draft or you can enter a specific depth value. The ship’s draft is determined by calculating the distance its bounding box extends below its origin, as set in the Simulation Object Editor.


      image

      i The formula for calculating the draft is: draft = height/2 - offset (Up)

      where height and offset are set in the Size group box in the Simulation Object Editor.


      image


      If you give this task to a submarine, VR-Forces assumes that it is moving on the surface.


      image

      i

      i

      For this task to work, your terrain must include S-57 data or depth information provided in a similar way.


      image


      To move a surface or subsurface vehicle to a location with path planning:

      1. Select the entity.

      2. Choose Task Movement Move to Location (Plan Path). The Move to Location (Plan Path) dialog box opens.

      3. Click on the terrain where you want the entity to move, or enter the coordinates of the location in the dialog box.

      4. Specify how you want VR-Forces to determine the minimum depth of water for the route.

      5. If you want to see the path displayed, select Display Route.

      6. Click OK.

      Movement Tasks for Entity-Level Scenarios — Move to Waypoint

      image

    21. Move to Waypoint

      You can order a simulation object to move to a point or a simulation object. If naviga- tion data is present, simulation objects take it into account in planning their path to the waypoint.

      Moving to a point is not the same as setting location. Setting location moves a simula- tion object instantaneously. Moving to a point causes a simulation object to travel through the terrain.

      If you want a ground entity to use the road network to move to a waypoint, use the Move to Waypoint (Plan Along Roads) task. For details about road movement, please see “Entity Movement On Roads and Off Roads,” on page 26-22.


      image

      i

      i

      Rotary-wing entities are not able to reach moving waypoints or land on moving ships. A rotary-wing entity will approach a given waypoint or landing point, but will never completely reach the goal.


      image


      To send a simulation object to a waypoint or entity:

      1. Select the simulation object.

        image

      2. Choose Task Movement Move to Waypoint, or click the Move to Waypoint button ( ) on the Tasks Toolbar. The Move to Waypoint dialog box opens.

      3. Optionally, filter the selection list.

      4. In the Name box, type the name of the waypoint or entity to move to, or select it in the list or on the terrain.

      5. Click OK.


        image

        i

        i

        When you task an air platform entity to move to an object, be sure to take into account the altitude setting for the object and the terrain the entity has to pass over to complete the task.


        image

        Movement Tasks for Entity-Level Scenarios — Move to Waypoint (Plan Along Roads)

        image

    22. Move to Waypoint (Plan Along Roads)

      The Move to Waypoint (Plan Along Roads) task directs an entity to move to a waypoint and use the road network if it is available.

      When an entity receives this task, it determines if there is a road network near by. If there is, it moves directly to the nearest point on the road network. Then it moves along the roads using road driving behavior until it gets to the point on the road that is closest to the destination. Then the entity moves off the road directly to the destination.

      For more information about road driving and how the path planning tasks work, please see “Entity Movement On Roads and Off Roads,” on page 26-22.

      To direct an entity to move to a waypoint using the road network:

      1. Select the entity.

      2. Choose Task Movement Move to Waypoint (Plan Along Roads). The Move to Waypoint (Plan Along Roads) dialog box opens.

      3. Select the waypoint.

      4. Click OK.

        Movement Tasks for Entity-Level Scenarios — Move to Waypoint (Plan Path)

        image

    23. Move to Waypoint (Plan Path)

      The Move to Waypoint (Plan Path) task applies to surface and subsurface entities. It plots a route to the waypoint based on the depth of water between the starting point and ending point. You specify the minimum depth required for the ship to maneuver. You can specify that the depth be based on the ship’s draft or you can enter a specific depth value. The ship’s draft is determined based by calculating the distance its bounding box extends below its origin, as set in the Simulation Object Editor.


      image

      i The formula for calculating the draft is: draft = height/2 - offset (Up)

      where height and offset are set in the Size group box in the Simulation Object Editor.


      image


      If you give this task to a submarine, VR-Forces assumes that it is moving on the surface.


      image

      i

      i

      For this task to work, your terrain must include S-57 data or depth information provided in a similar way.


      image


      To move a surface or subsurface vehicle to a waypoint with path planning:

      1. Select the entity.

      2. Choose Task Movement Move to Waypoint (Plan Path). The Move to Waypoint (Plan Path) dialog box opens.

      3. Select the waypoint to move to.

      4. Specify how you want VR-Forces to determine the minimum depth of water for the route.

      5. If you want to see the path displayed, select Display Route.

      6. Click OK.


      image

    24. Orbit

      Movement Tasks for Entity-Level Scenarios — Patrol Route

      The Orbit task allows a fixed-wing aircraft to circle around a point without needing to create a route for it to follow.

      To specify an orbit task:

      1. Select the entity that you want to orbit.

      2. Choose Task Movement Orbit. The Orbit dialog box opens.

      3. Specify the coordinates of a point on the terrain around which the entity should orbit. You can click on the terrain to specify the points.

      4. Specify the altitude at which to fly.

      5. Specify the radius of the circle.

      6. Select or clear the Clockwise option to specify the direction of travel.

      7. Click OK.


    25. Patrol Route

      When a simulation object patrols along a route, it moves to the nearest vertex of the route, to the end point, back to the beginning of the route, and then continues going back and forth along the route until given another command.

      If a human is moving along a route outside of a navigation area and you move it away from the route or change the route, the entity plans a path to the route vertex it is moving to rather than moving to the nearest point on the route and then proceeding to the target vertex.

      To order a simulation object to patrol a route:

      1. Select the simulation object.

        image

      2. Choose Task Movement Patrol Route, or click the Patrol Route button ( ) on the Tasks Toolbar. The Patrol Along Route dialog box opens.

      3. In the Name box, type the name of the route to patrol, or select the route in the list or on the terrain.

      4. Click OK.


        image

        i

        i

        When you task an air platform entity to follow a route, be sure to take into account the altitude of the vertices and the terrain the entity has to pass over to complete the task.


        image

        Movement Tasks for Entity-Level Scenarios — Patrol Between

        image

    26. Patrol Between

      A simulation object can patrol between two point objects, simulation objects, or both. When a simulation object patrols between two objects, it goes to the starting object, then moves back and forth between the two objects.

      To order a simulation object to patrol between two objects:

      1. Select the entity.

      2. Choose Task Movement Patrol Between, or click the Patrol Between button image) on the Tasks Toolbar. The Patrol Between dialog box opens.

      3. In the Name box for Point 1, type the name of the first object to patrol between, or select an object in the list or on the terrain.

      4. In the Name box for Point 2, type the name of the second object to patrol between, or select an object in the list or on the terrain.

      5. Click OK.


        image

        i

        i

        When you task an air platform entity to patrol between objects, be sure to take into account the altitude of the objects and the terrain the entity has to pass over to complete the task.


        image


    27. Pattern Hold (Location)

      The Pattern Hold (Location) task causes a fixed-wing or rotary-wing entity to execute a standard hold pattern at the specified location.

      To assign a pattern hold (location) task:

      1. Select a fixed-wing or rotary-wing entity.

      2. Choose Task Movement Pattern Hold (Location). The Pattern Hold (Location) dialog box opens.

      3. Enter the location or select it on the terrain.

      4. Specify the heading, speed, and altitude for the hold pattern.

      5. Specify the turn direction for the hold pattern.

      6. Click OK.

        Movement Tasks for Entity-Level Scenarios — Rotary Wing Airlift Cargo to Location

        image

    28. Pattern Hold (Waypoint)

      The Pattern Hold (Waypoint) task causes a fixed-wing or rotary-wing entity to execute a standard hold pattern at the specified waypoint.

      To assign a pattern hold (waypoint) task:

      1. Select a fixed-wing or rotary-wing entity.

      2. Choose Task Movement Pattern Hold (Waypoint). The Pattern Hold (Waypoint) dialog box opens.

      3. Select the waypoint.

      4. Specify the heading, speed, and altitude for the hold pattern.

      5. Specify the turn direction for the hold pattern.

      6. Click OK.


    29. Rotary Wing Airlift Cargo to Location

      The Rotary Wing Airlift Cargo to Location task causes an unmanned rotary-wing aircraft to move to a list of objects, embark them onto itself, move to a location, and disembark the objects. The objects must be configured as embarkable.

      If the total weight of the objects plus the weight of the aircraft is greater than the aircraft can carry, the aircraft will embark the objects, but be unable to fly.

      The unmanned aircraft needs to use the Quadcopter or Quadcopter Heavy Lift move- ment dynamics system.

      To airlift cargo to a destination:

      1. Select an unmanned aircraft.

      2. Choose Task Movement Rotary Wing Airlift Cargo to Location. The Rotary Wing Airlift Cargo To Location dialog box opens.

      3. Optionally, filter the list of object types.

      4. Type the name of an object in the Name box, or in the Cargo Objects list, select one or more objects.

      5. In the Cruise Altitude box, specify the altitude at which you want the aircraft to fly.

      6. Specify the destination location by typing in the coordinates, or click the Destina- tion Location filter button image) to give the Destination Location focus, and click on the terrain to specify the destination location.

      7. Click OK.

        Movement Tasks for Entity-Level Scenarios — Rotary Wing Land

        image

    30. Rotary Wing Land

      The Rotary Wing Land task automates the process of landing a rotary-wing aircraft. Rotary-wing aircraft can land on points.


      image

      !

      !

      Although it is possible to land an entity on another entity, such as an aircraft carrier, if you want to embark an entity, you must use the Embark task, not a landing task.


      image


      To land a rotary-wing aircraft:

      1. Select the entity.

      2. Choose Task Movement Rotary Wing Land. The Rotary Wing Land dialog box opens.

      3. In the Name box, type the name of the waypoint on which you want the entity to land, or select the waypoint in the list or on the terrain.

      4. Click OK.


    31. Rotary Wing Retrieve Cargo

      The Rotary Wing Retrieve Cargo task causes an unmanned aircraft to move to one or more cargo items and embark them onto itself. It hovers at the location of the last item retrieved until given further tasks.

      The unmanned aircraft needs to use the Quadcopter or Quadcopter Heavy Lift move- ment dynamics system.

      To cause a rotary-wing aircraft to retrieve cargo:

      1. Select an unmanned aircraft.

      2. Choose Task Movement Rotary Wing Retrieve Cargo. The Rotary Wing Airlift Cargo To Location dialog box opens.

      3. Optionally, filter the list of object types.

      4. Type the name of an object in the Name box or in the Cargo Objects list, select one or more objects.

      5. In the Cruise Altitude box, specify the altitude at which you want the aircraft to fly.

      6. Click OK.

        Movement Tasks for Entity-Level Scenarios — Sail Heading

        image

    32. Rotary Wing Unload Cargo

      The Rotary Wing Unload Cargo task causes a rotary-wing aircraft to unload (disem- bark) its cargo at the current location of the aircraft.

      To unload cargo:

      1. Select an unmanned aircraft.

      2. Choose Task Movement Rotary Wing Unload Cargo. The aircraft unloads its cargo.


    33. Sail Heading

      The Sail Heading task causes a surface entity to sail towards the specified heading. After turning to the heading, the entity moves at its ordered speed indefinitely.

      To assign a sail heading task:

      1. Select the entity.

      2. Choose Task Movement Sail Heading. The Sail Heading dialog box opens.

      3. Specify a heading in the indicated units (radians or degrees).

      4. Specify the diameter of the turn.

      5. Specify the direction of the turn, as follows:

        • Toward Heading. Chooses the most direct turn.

        • Port. Turns to port until it reaches the heading.

        • Starboard. Turns to starboard until it reaches the heading.

      6. Click OK.

        Movement Tasks for Entity-Level Scenarios — Turn to Heading

        image

    34. Turn to Heading

      The Turn to Heading task provides a realistic way for ground vehicles to turn to a new heading. Rather than turning instantly, as happens with the Heading request, a vehicle pivots or makes a K-turn to the new heading. The turning behavior for an entity is controlled by its can-pivot parameter in the object parameter database.

      To order an entity to turn to a heading:

      1. Select the entity.

      2. Choose Task Movement Turn to Heading. The Turn to Heading dialog box opens.

      3. Type a heading.

      4. In the Relative To list, select one of the following options:

        • North. Turn to the specified absolute heading.

        • Current Heading. Turn the specified number of degrees relative to the current heading.

        • Host (if embarked). If embarked, turn to the specified heading relative to the host simulation object.

      5. Click OK.


image

28. Engagement Tasks for Entity-Level Scenarios


This chapter describes tasks in the engagement category that apply to entity-level scenarios.

Arm Mine at Depth 28-3

Attack Aircraft with Guns 28-3

Drop Naval Depth Charge 28-4

Drop Naval Depth Charge at Location 28-4

Drop Naval Mine 28-5

Drop Naval Mines Along Route 28-6

Execute Close Air Support 28-7

Explode Charge at Depth 28-9

Fire at Target 28-9

Fire Cruise Missile 28-10

Fire for Effect Tasks 28-11

Firing Naval Guns 28-12

Lase Target 28-12

Launch Anti-Submarine Missile (Vertical) 28-12

Launch Counter Measures 28-13

Launch Smoke 28-13

Launch Torpedo 28-14

Anti-ship (Fixed Depth) 28-14

Anti-Submarine 28-15

Place IED 28-16

Provide Suppressive Fire 28-17

Provide Suppressive Fire at Location 28-18

image

Engagement Tasks for Entity-Level Scenarios

Release Bomb Tasks 28-18

Sector Search Operation 28-20

Strafe Ground Target 28-21

Sweep Naval Mines 28-23

Throw Grenade Tasks 28-23

Throw Grenade at Location 28-23

Throw Grenade at Target 28-24

Engagement Tasks for Entity-Level Scenarios — Attack Aircraft with Guns

image

    1. Arm Mine at Depth

      If a naval mine has been deployed, Arm Mine at Depth lets you change the mine’s parameters.

      Arm Mine at Depth is a system scripted task. It is disabled by default.

      To arm a mine:

      1. Select the mine.

      2. Choose Task Arm Mine at Depth. The Arm Mine at Depth dialog box opens.

      3. Specify the depth at which to arm the mine.

      4. Specify the radius within which target entities will detonate the mine.

      5. Optionally, specify a time when the mine will be armed, in days and hours:minutes:seconds.

      6. In the Targets list, add the types of entities that can trigger the mine, as follows:

        image

        1. Click the Add button ( ). The Entity Type dialog box opens.

        2. Build an entity type by selecting options from the lists for each enumeration component or type an enumeration.

        3. Click OK.

      7. To specify that only hostile entities will set off the mine, select Hostile Only. If this setting is cleared, any entity will set off the mine.

      8. Click OK.


    2. Attack Aircraft with Guns

      The Attack Aircraft with Guns task commands aircraft that have mounted guns, such as the A10, to attack other aircraft with their guns rather than air-to-air missiles.

      To issue the Attack Aircraft with Guns task:

      1. Select an aircraft entity that has a gun.

      2. Choose Task Engagement Attack Aircraft with Guns. The Attack Aircraft with Guns dialog box opens.

      3. Select the target entity.

      4. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Drop Naval Depth Charge

        image

    3. Drop Naval Depth Charge

      The Drop Naval Depth Charge task drops a depth charge at the current location of the entity. To execute this task, an entity must have a Naval Depth Charge Deployment weapon system.

      To drop a naval depth charge:

      1. Select the entity.

      2. Choose Task Engagement Drop Naval Depth Charge. The Drop Naval Depth Charge dialog box opens.

      3. In the Naval Depth Charge list, select the type of depth charge to drop.

      4. Specify the depth at which you want the depth charge to explode.

      5. Click OK.


    4. Drop Naval Depth Charge at Location

      The Drop Naval Depth Charge at Location task causes an entity to move to the speci- fied location and drop a depth charge. To execute this task, an entity must have a Naval Depth Charge Deployment weapon system.


      image

      i

      i

      In this task, the location is the location of the entity when it drops the depth charge. Since the entity is flying, the location must include a reasonable altitude.


      image


      To drop a naval depth charge at a location:

      1. Select the entity.

      2. Choose Task Engagement Drop Naval Depth Charge at Location. The Drop Naval Depth Charge At Location dialog box opens.

      3. In the Naval Depth Charge list, select the type of depth charge to drop.

      4. Specify the depth at which you want the depth charge to explode.

      5. Specify the location where you want to drop the depth charge.

        By default, this task uses the altitude of the entity at the time the task is assigned as the altitude for the drop location. (Use Current Altitude check box.) If you specify an altitude and the check box is selected, VR-Forces ignores the altitude you entered and uses the current entity altitude. If you want to specify the altitude, clear the check box and make sure that you specify the altitude in the Altitude group box. If you click on the terrain to specify the X, Y location, the altitude gets set to 0, so be sure to enter the altitude you want after clicking on the terrain.

      6. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Drop Naval Mine

        image

    5. Drop Naval Mine

      The Drop Naval Mine task allows entities with a Naval Mine Deployment system to drop naval (underwater) mines at their current location.

      To drop a naval mine:

      1. Select the entity.

      2. Choose Task Engagement Drop Naval Mine. The Drop Naval Mine dialog box opens.

      3. In the Naval Mine list, select the type of mine to drop.

      4. In the Mine Depth field, set the depth to drop the mine. Positive numbers are below sea level.

      5. In the Arming Delay fields, set the time to elapse before the mine becomes armed. The first field is days. The second field is Hours:Minutes:Seconds.

      6. In the Detonate Proximity field, set the distance from the mine within which a target entity will detonate the mine.

      7. In the Trigger Entity Types list, add the types of entities that can trigger the mine, as follows:

        image

        1. Click the Add button ( ). The Entity Type dialog box opens.

        2. Build an entity type by selecting options from the lists for each enumeration component or type an enumeration.

        3. Click OK.

      8. To specify that only hostile entities will set off the mine, select Hostile Only. If this setting is cleared, any entity will set off the mine.

      9. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Drop Naval Mines Along Route

        image

    6. Drop Naval Mines Along Route

      The Drop Naval Mines Along Route task allows entities with a Naval Mine Deploy- ment system to drop naval (underwater) mines while they travel along a route.

      To drop naval mines along a route:

      1. Select the entity.

      2. Choose Task Engagement Drop Naval Mines Along Route. The Drop Naval Mines Along Route dialog box opens.

      3. Select the route to follow.

      4. In the Mine Spacing field, specify the distance between each mine.

      5. In the Naval Mine list, select the type of mine to drop.

      6. In the Mine Depth field, set the depth to drop the mine. Positive numbers are below sea level.

      7. In the Arming Delay fields, set the time to elapse before the mine becomes armed. The first field is days. The second field is Hours:Minutes:Seconds.

      8. In the Detonate Proximity field, set the distance from the mine within which a target entity will detonate the mine.

      9. In the Trigger Entity Types list, add the types of entities that can trigger the mine, as follows:

        image

        1. Click the Add button ( ). The Entity Type dialog box opens.

        2. Build an entity type by selecting options from the lists for each enumeration component or type an enumeration.

        3. Click OK.

      10. To specify that only hostile entities will set off the mines, select Hostile Only. If this setting is cleared, any entity will set off the mine.

      11. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Execute Close Air Support

        image

    7. Execute Close Air Support

      The Execute Close Air Support task assigns a fixed-wing fighter or bomber a close air support (CAS) task based on a 9-Line Briefing. You can call for a bombing run or a strafing run. The entity being tasked must be in the air to execute this task.


      image

      i

      i

      A 9-Line Briefing is a format used by U.S. armed forces to call in CAS. The Execute Close Air Support dialog box explicitly or implicitly requests all of the information in a 9-Line Briefing. However, the scripted task does not use all of this information to simulate CAS. (The procedure notes which fields are not used.) The task has parameters for all 9 lines to provide simulation authenticity. Since this is a scripted task, you could modify it to use all of the parameters.


      image


      To execute close air support:

      1. Select the entity you want to execute close air support.

      2. Choose Task Engagement Execute Close Air Support. The Execute Close Air Support dialog box opens (Figure 28-1).

      3. In the Initial Point section, specify the location from which the aircraft should line up with the target by entering location values or clicking on the terrain.

      4. In the Heading box, specify the approach heading. Optionally, specify an offset if you want the entity to favor a particular side of the line of approach.

      5. In the Distance box, specify the distance from the initial point to the target. This information is not used by the task.

      6. Select the target. Target selection satisfies lines 4, 5, and 6 of a 9-Line briefing, because it provides the location, altitude, and name of the target.

      7. In the Mark Type box, specify how the target is marked. This information is not used by the task.

        Engagement Tasks for Entity-Level Scenarios — Execute Close Air Support

        image


        image

        Figure 28-1. Execute Close Air Support dialog box

      8. If you are using a laser designator to mark the target, enter the laser code. (If you specify a laser code, an entity in the simulation must be lasing the target for the CAS to work.)

      9. In the Friendlies box, specify the distance and direction of friendly forces from the target. This information is not used by the task.

      10. In the Egress Heading box, specify the heading by which the attacking entity should leave after firing at the target. It will continue on this heading until it is given another task.

      11. In the Attack Information section, select bomb or gun. If you select gun, the entity executes a strafing attack.

      12. If you selected bomb, select a Bomb Choice and Bombing Altitude.

      13. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Fire at Target

        image

    8. Explode Charge at Depth

      The Explode Charge at Depth task explodes a depth charge at the specified depth. You can use this task to explode a depth charge that has been deployed, but has not yet exploded.

      Explode Charge at Depth is a system scripted task. It is disabled by default.

      To explode a depth charge:

      1. Select the depth charge.

      2. Choose Task Explode Charge at Depth. The Explode Charge at Depth dialog box opens.

      3. Specify the depth.

      4. Click OK.


    9. Fire at Target

      The Fire at Target task commands an entity to fire at a specific target. You can specify which weapon system to use and how many rounds to fire.

      When you issue this task, the entity ignores its rules of engagement and force types. Entities will fire at their own force if told to do so. The shooter must have line-of-sight to the target and have an appropriate weapon system and ammunition for the target.

      To order an entity to fire at a target:

      1. Select the entity you want to fire.

      2. Choose Task Engagement Fire at Target, or click the Fire at Target button image) on the Last Selected Object Panel or the Tasks Toolbar. The Fire at Target dialog box opens.

      3. Select the target entity.

      4. In the Weapon Selection group box, select an option as follows:

        • To let VR-Forces choose the weapon, select Automatic.

        • To choose the weapon yourself, select Manual and select a weapon from the list.

      5. In the Maximum Rounds to Fire box, enter the number of rounds you want the entity to fire. (The entity stops firing when the target is destroyed or when the maximum number of rounds has been fired, whichever comes first.)

        Engagement Tasks for Entity-Level Scenarios — Fire Cruise Missile

        image

    10. Fire Cruise Missile

      A cruise missile can fly directly to a target or follow a route.

      To fire a cruise missile:

      1. Select an entity that has cruise missiles.

      2. Choose Task Engagement Fire Cruise Missile. The Fire Cruise Missile dialog box opens (Figure 28-2).



        image

        Figure 28-2. Fire Cruise Missile dialog box

      3. Select the target from the list or on the terrain, or type its name in the Name box. Targets can be entities or points.

      4. Select a route for the missile to follow or select the No Route check box. If no route is selected, the missile flies directly to the target.

      5. Specify the ordered speed for the missile.

      6. Specify the detonation proximity for the warhead. It will detonate within this range of the selected target.

      7. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Fire for Effect Tasks

        image

    11. Fire for Effect Tasks

      You can task artillery entities and surface vessels that have naval guns to fire for effect. The three options are:

      • Fire-for-Effect on Entity.

      • Fire-for-Effect on Location, where location is a point on the terrain.

      • Fire-for-Effect on Target, where a target is a waypoint.

      If an entity has more than one weapon, you can select multiple weapons to fire. However, they will all fire on the same target. You cannot target them independently.

      To assign a Fire-for-Effect task:

      1. Select the entity to which you want to assign the task.

      2. Choose Task Engagement Fire-for-Effect on Entity (or Location or Target). The appropriate dialog box opens.

      3. Identify the target as follows:

4.


image

i For FFE Entity and FFE Target, you can filter the target list.

image

  1. In the Select Weapons list, select the weapons that you want to fire.

  2. Specify the number of rounds.

  3. Optionally, specify the height above the terrain at which rounds should detonate.

  4. Click OK.


    image

    i

    i


image

Engagement Tasks for Entity-Level Scenarios — Lase Target

image

      1. Firing Naval Guns

        Ordinarily, naval guns fire their munitions in a parabola, similar to artillery. However, they can also fire directly at a target if the following conditions are true:

        • The target’s range is greater than the weapon’s minimum range, but less than the first value in its range list.

        • The capable-of-direct-alignment parameter for the weapon system’s naval-gun- controller is set to True.

        • The firing entity has line-of-sight to the target.


    1. Lase Target

      The Lase Target task simulates aiming a laser beam at a target to guide a laser guided weapon. By default, entities with laser capability lase autonomously. Use this task if you want to lase a specific target. An entity can lase a target while it is executing a move- ment task.

      To lase a target, an entity must have a Laser Designator system.

      To lase a target:

      1. Select the entity that will aim the laser.

      2. Choose Task Engagement Lase Target. The Lase Target dialog box opens.

      3. Select the entity that you want to lase.

      4. Click OK.


    2. Launch Anti-Submarine Missile (Vertical)

      The Launch Anti-Submarine Missile (Vertical) task lets a surface entity launch a missile that flies to the vicinity of the target and then drops a homing torpedo. To execute this task, an entity needs an Anti-Submarine Missile (Vertically Launched) weapon system.

      To launch an anti-submarine missile:

      1. Select the surface entity.

      2. Choose Task Engagement Launch Anti-Submarine Missile (Vertical). The Launch Anti-Submarine Missile (Vertical) dialog box opens.

      3. Select the target entity.

      4. Specify the location at which to drop the homing torpedo.

      5. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Launch Smoke

        image

    3. Launch Counter Measures

      Fixed-wing and rotary-wing entities can launch counter measures, such as chaff and flares. Launch Counter Measures is not an exclusive task. It does not interrupt an entity’s current task. (For more information, please see “Launching Counter Measures (Chaff and Flare),” on page 9-19.)

      To launch counter measures:

      1. Select the entity that you want to launch counter measures.

      2. Choose Task Engagement Launch Counter Measures. The Launch Counter Measures dialog box opens.

      3. In the Counter Measure Types list, select the type of counter measures you want to launch.

      4. In the Number To Fire box, specify the number of counter measures to launch.

      5. In the Time Between Fires box, specify the amount of time, in seconds, between each counter measure launch.

      6. Click OK.


    4. Launch Smoke

      The Launch Smoke task causes an entity to create a smoke cloud. The cloud is created as an environmental object. It grows over time.

      An entity can launch a smoke cloud towards a threat or in a specific direction. Smoke clouds affect sensors. They do not affect entity movement.


      image

      i

      i

      Tactical smoke is delivered by the M250 smoke grenade launcher. An entity must have this system to execute this task.


      image


      To launch a smoke cloud:

      1. Select the entity that you want to launch smoke.

      2. Choose Task Engagement Launch Smoke. The Launch Smoke dialog box opens.

      3. Select At Nearest Threat or Toward Compass Heading.

      4. If you selected Toward Compass Heading, specify a compass heading, in degrees.

      5. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Launch Torpedo

        image

    5. Launch Torpedo

Subsurface entities can launch two types of anti-ship torpedoes. One moves at a fixed depth; one homes in on the center of the target. In both cases, the torpedo travels at an initial bearing for a fixed distance before it homes in on the target. The Launch Torpedo tasks are system scripted tasks.


image

i

i

Torpedoes rise to target depth at a fixed rate. If a submarine is quite close to a target when it fires, the torpedo might not be able to rise to target depth in the distance from the submarine to the target. If this happens, it circles until it reaches target depth.


image


      1. Anti-ship (Fixed Depth)

        To launch a torpedo that moves at a fixed depth:

        1. Select a subsurface entity.

        2. Choose Task Engagement Launch Torpedo Anti-ship (Fixed Depth). The Anti-ship (Fixed Depth) dialog box opens.

        3. Optionally, filter the entity list.

        4. Select the target entity.

        5. In the Homing Start Delay box, enter the amount of time that the torpedo should travel on its initial bearing.

        6. In the Cruise Depth box, specify the depth the torpedo should travel at. It will remain at this depth.

        7. In the Initial Bearing box, specify the bearing the torpedo should travel at until it begins homing in on the target.

        8. In the Proximity Trigger Distance box, set the distance from a target at which the torpedo will detonate.

        9. Click OK.

          Engagement Tasks for Entity-Level Scenarios — Launch Torpedo

          image

      2. Anti-Submarine

        The anti-submarine torpedo homes in on the center of the target.

        To launch an anti-submarine torpedo:

        1. Select a subsurface entity.

        2. Choose Task Engagement Launch Torpedo Anti-submarine. The Anti- Submarine dialog box opens.

        3. Optionally, filter the entity list.

        4. Select the target entity.

        5. In the Homing Start Delay box, enter the amount of time that the torpedo should travel on its initial bearing.

        6. In the Initial Bearing box, specify the bearing the torpedo should travel at until it begins homing in on the target.

        7. In the Proximity Trigger Distance box, set the distance from the target at which the torpedo will detonate.

        8. Click OK.

Engagement Tasks for Entity-Level Scenarios — Place IED

image

    1. Place IED

      The Place IED task lets a human entity place an improvised explosive device (IED) at a particular location and move to a post-placement location. This task also sets the parameters for how the IED will be armed.

      To assign a place IED task to a human entity:

      1. Select the entity.

      2. Choose Task Engagement Place IED. The Place IED dialog box opens (Figure 28-3).


        image

        Figure 28-3. Place IED dialog box

      3. Enter the location where the IED should be placed, or click on the terrain to specify the location.

      4. In the Placement Duration box, enter the amount of time it takes to place the IED.

      5. Select a fuse type from the Fuse Type list.

      6. For a timed delay fuse, specify the time to delay in the Time Delay box.

      7. For a proximity fuse, specify the distance from the IED within which another entity will trigger the IED.

      8. Enter the location where the entity should move to after it places the IED, or click on the terrain to specify the location.

        Engagement Tasks for Entity-Level Scenarios — Provide Suppressive Fire

        image


      9. In the Arming Location list select Arm at Placement Location to arm the IED as soon as it is placed, or Arm at Post Placement Location to arm it when the entity reaches the post-placement location.

      10. Click OK.


    2. Provide Suppressive Fire

      The Provide Suppressive Fire task tells an entity to fire at a point, along a line, or in an area, one meter above the terrain. For more information, please see “Suppressive Fire Tasks,” on page 26-32.


      image

      i The target of suppressive fire must be at least 25 meters away.

      image

      To order suppressive fire on a point, a line, or in an area:

      1. Select the entity that will deliver suppressive fire.

      2. Choose Task Engagement Provide Suppressive Fire. The Provide Suppressive Fire dialog box opens.

      3. Select the tactical graphic to fire at.

      4. In the Duration of Rapid Fire box, type the number of seconds for the rapid fire.

      5. In the Total Fire Time box, type the number of minutes the entity should provide suppressive fire.

      6. In the Maximum Round to Fire box, type the maximum number of rounds to fire.

      7. In the Gun list, select the gun to use.

      8. Click OK.

      Engagement Tasks for Entity-Level Scenarios — Provide Suppressive Fire at Location

      image

    3. Provide Suppressive Fire at Location

      The Provide Suppressive Fire on Location task tells an entity to fire at a location, one meter above the location. For more information, please see “Suppressive Fire Tasks,” on page 26-32.


      image

      i The target of suppressive fire must be at least 25 meters away.

      image

      To order suppressive fire on a location:

      1. Select the entity that will deliver suppressive fire.

      2. Choose Task Engagement Provide Suppressive Fire at Location. The Provide Suppressive Fire at Location dialog box opens.

      3. Specify the location.

      4. In the Duration of Rapid Fire box, type the number of seconds for the initial burst of rapid fire.

      5. In the Total Fire Time box, type the number of minutes the entity should provide suppressive fire.

      6. In the Maximum Round to Fire box, type the maximum number of rounds to fire.

      7. In the Gun list, select the gun to use.

      8. Click OK.


    4. Release Bomb Tasks

      Fixed-wing entities can release bombs targeted to a laser spot, a location, or an entity. The Release Bomb on Laser Spot task requires that another entity lase the target. You must synchronize the laser code for the bomber with the laser code for the lasing entity. Use of lasers is described in:

      Engagement Tasks for Entity-Level Scenarios — Release Bomb Tasks

      image


      The Release Bomb on Target and Release Bomb on Location tasks cause a bomb to be immediately dropped. The task assumes that the target is in front of the aircraft. The targetable area is a circle whose radius is defined by the altitude of the airplane and its maximum range.

      The bomb navigates toward its target based on max-range and max-range-altitude parame- ters (configurable in the Simulation Object Editor). A bomb can navigate max-range meters laterally if it is at max-range-altitude meters above the target. As the altitude changes, the distance it can travel changes accordingly, so at half of max-range-altitude it can travel half of max-range.

      The bomb follows a straight line path from its launch to the point it is navigating to, assuming it can reach it. If its target point is out of range, it gets as close to the target as it can. If the target point moves, the bomb changes course and heads for the new target point.


      image

      i

      i

      Use of a Release Bomb task requires that you determine if the airplane is in range of the target. The Execute Close Air Support task ensures that the airplane is within range of the target before it drops its bomb. Therefore, we recommend using that task rather than one of the Release Bomb tasks.


      image


      The Release Bomb on Laser Spot task steers the bomb towards the laser point.

      To assign a release bomb task:

      1. Select the entity that will release the bomb.

      2. Choose Task Engagement task, where task is Release Bomb on Laser Spot, Release Bomb on Location, or Release Bomb on Target. The appropriate dialog box opens.

      3. In the Bomb Types list, select the type of bomb you want to drop.

      4. In the Detonation Proximity box, enter the distance from the target at which the bomb should detonate.

      5. For Release Bomb on Location, specify the location. For Release Bomb on Target, select the target.

      6. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Sector Search Operation

        image

    5. Sector Search Operation

      The Sector Search Operation task tasks an embedded entity to fly a sector search and rescue pattern. In addition to the basic search and rescue parameters, you have the following options:

      • If there are no undeployed embedded entities available, divert an already deployed entity to do the search.

      • Force the parent entity to wait until the search is complete and the embedded entity is recovered until it continues with its plan or allow the parent entity to continue with its plan while the search is underway.

      To execute a sector search operation:

      1. Choose an entity that has embedded entities.

      2. Choose Task Sector Search Operation. The Sector Search Operation dialog box opens.

      3. Select the Allow Diversion check box if you want a deployed entity to be diverted to this task if necessary.

      4. Select the Recover When Finished check box if you want the parent entity to wait until it recovers the deployed entity before it continues with its plan.

      5. Specify the starting point of the search.

      6. In the Leg box, specify the length of each leg of the search.

      7. In the Altitude box, specify the altitude the search aircraft should fly at.

      8. In the Air Speed box, specify the speed of the search aircraft.

      9. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Strafe Ground Target

        image

    6. Strafe Ground Target

      Fixed-wing entities that have the appropriate armament can strafe ground targets. The Strafe Ground Target task takes the following parameters:

      • Target Point. The target point to strafe.

      • Initial Point. The point at which the aircraft reaches strafing altitude and lines up to strafe the target point. VR-Forces enforces a minimum distance from the initial point to the target. It varies based on the plane’s dive angle, strafe range, entry speed, and other parameters. Two kilometers is a good minimum for most entities. If the initial point is too close to the target, VR-Forces sends an error message to the entity console.

      • Target Types. The type of entity or object to be targeted at the target point. If you specify none, the entity strafes the target location. If you specify an object type, the entity looks for that object type. If it finds the target type, it strafes it. If it does not find the target type, it either strafes the target point (default behavior) or aborts the strafing run, depending on the state of the Abort Without Target check box.

      • Egress Maneuver and Egress Heading. The way the aircraft should exit the strafing run and the heading at which it exits.

      You can also initiate a strafing run from the Execute Close Air Support task. Table 28-1 shows how arguments to the Execute Close Air Support task map to the Strafe Ground Target task.

      image

      Table 28-1: CAS to Strafe argument mapping


      CAS Argument Strafe Ground Target Argument

      CAS Argument Strafe Ground Target Argument

      Initial Point Initial Point.

      Target Point Target Point.

      Target: a waypoint Target: an entity

      Offset: none Offset: left Offset: right

      Target Type: None (target location). Target Type: Target the indicated entity.

      Egress Maneuver: Immediate Climb. Egress Maneuver: Juke Left.

      Egress Maneuver: Juke Right. Abort without target.

      Egress Heading Final Egress Heading.

      image

      Engagement Tasks for Entity-Level Scenarios — Strafe Ground Target

      image


      To strafe a ground target:

      1. Select the entity that will make the strafing run.

      2. Choose Task Engagement Strafe Ground Target. The Strafe Ground Target dialog box opens (Figure 28-4).


        image

        Figure 28-4. Strafe Ground Target dialog box

      3. Click the terrain to specify the initial point or type the coordinates.

      4. Select the target point.

      5. Optionally, select a target type.

      6. If you select a target type other than none, select the Abort Without Target check box to abort the strafing run if the target type is not found. Clear the check box if you want the entity to strafe the target point if the target type is not found.

      7. Select an egress maneuver.

      8. Optionally, specify an egress heading.

      9. Click OK.

        Engagement Tasks for Entity-Level Scenarios — Throw Grenade Tasks

        image

    7. Sweep Naval Mines

      The Sweep Naval Mines task causes an entity to look for and disable naval mines along a route. It looks within a specified distance from the route. An error rate specifies a percentage chance that the entity will detect a mine, but not disable it. The Sweep Naval Mines task is available to surface entities that have a Naval Mine Sweep system.

      To assign the Sweep Naval Mines task:

      1. Select the entity.

      2. Choose Task Movement Sweep Naval Mines. The Sweep Naval Mines dialog box opens.

      3. Select the route to follow.

      4. Specify the sensing range. The default is 300 meters.

      5. Optionally, specify the disarm failure probability. This is the percentage chance that a mine will be found, but not disabled.

      6. Click OK.


    8. Throw Grenade Tasks

Infantry characters can throw hand grenades at a target or at a location. An entity can throw the following types of grenades:


      1. Throw Grenade at Location

        To throw a hand grenade to a location:

        1. Select the entity.

        2. Choose Task Engagement Throw Grenade at Location. The Throw Grenade at Location dialog box opens.

        3. In the Grenade Type list, select the type of grenade to throw.

        4. Specify the location.

        5. Click OK.

          Engagement Tasks for Entity-Level Scenarios — Throw Grenade Tasks

          image

      2. Throw Grenade at Target

        To throw a hand grenade at a target:

        1. Select the entity.

        2. Choose Task Engagement Throw Grenade at Target. The Throw Grenade at Target dialog box opens.

        3. Specify the target.

        4. In the Grenade Type list, select the type of grenade to throw.

        5. Click OK.


image

29. Human and Crowd Tasks


This chapter describes the tasks for humans and crowds that apply to entity-level scenarios. Movement and engagement tasks that apply to humans are described in Chapter 27, Movement Tasks for Entity-Level Scenarios and Chapter 28, Engagement Tasks for Entity-Level Scenarios.

Civilian Idle 29-2

Close Door 29-2

Close Window 29-2

Create Pedestrians 29-3

Crowd Along Line 29-3

Crowd Around Location 29-4

Crowd Around Object 29-4

Crowd in Front of Entity 29-5

DI-Guy Animation 29-5

Disperse Crowd 29-5

Flee from Entities 29-6

Open Door 29-6

Open Window 29-6

Protest Around Location 29-7

Protest Along Line 29-7

Wander 29-7

Wander In Area 29-8

Human and Crowd Tasks — Civilian Idle

image

    1. Civilian Idle

      The Civilian Idle task causes a human character to stand and cycle through DI-Guy animations typical of a person standing in a group.

      To assign a civilian idle task:

      1. Select the human characters.

      2. Choose Task Movement Civilian Idle.


    2. Close Door

      If a human is within approximately one meter of an open door, this task causes the door to close. This task applies to doors controlled by switch nodes in the terrain, not articu- lated parts.

      To close a door:

      1. Move a human to within one meter of an open door.

      2. Choose Task Terrain Close Door.


    3. Close Window

      If a human is within approximately one meter of an open window, this task causes the window to close. This task applies to windows controlled by switch nodes in the terrain, not articulated parts.

      To close a window:

      1. Move a human to within one meter of an open window.

      2. Choose Task Terrain Close Window.


        image

    4. Create Pedestrians

      Human and Crowd Tasks — Crowd Along Line

      The Create Pedestrians task adds pedestrians to a crowd. If the crowd is part of a pedes- trian area, the new pedestrians wander within the area. If the crowd is not part of a pedestrian area, their wandering is unrestricted.


      image

      i

      i

      When the Create Pedestrians task runs, it gives each new pedestrian a Move To Location task, followed by a Wander task. The Create Pedestrians task is not complete until all the Wander tasks have been sent. Therefore, the task does not complete as quickly as you might expect simply based on when the pedestrians get created.


      image


      To add pedestrians to a crowd:

      1. Select the crowd or select a pedestrian area.

      2. Choose Task Create Pedestrians.

      3. Select a placement option.

      4. Click OK.


    5. Crowd Along Line

      The Crowd Along Line task causes a crowd to gather to the left or right of a line at its center point.

      To cause a crowd to gather along a line:

      1. Select the crowd.

      2. Choose Task Movement Crowd Along Line. The Crowd Along Line dialog box opens.

      3. Select the line the crowd should crowd along.

      4. Specify left or right of the line.

      5. Click OK.

        Human and Crowd Tasks — Crowd Around Location

        image

    6. Crowd Around Location

      The Crowd Around Location task causes a crowd unit to cluster around the specified location.

      To cause a crowd to crowd around a location:

      1. Select the crowd.

      2. Choose Task Movement Crowd Around Location. The Crowd Around Loca- tion dialog box opens.

      3. Click on the terrain to specify the location or enter the coordinates in the dialog box.

      4. Click OK.


    7. Crowd Around Object

      The Crowd Around Object task causes a crowd unit to cluster around the specified simulation object or point.


      image

      i

      i

      The Crowd Around Object task calculates target locations for the members of the crowd to move to that are greater than or equal to the minimum distance specified from the object. However, due to interactions between the crowd members as they move, it is possible that some will end up closer to the target object than the minimum distance.


      image


      To cause a crowd to crowd around a simulation object:

      1. Select the crowd.

      2. Choose Task Movement Crowd Around Object. The Crowd Around Object dialog box opens.

      3. In the Filter list, select All Entities or Points.

      4. Select the simulation object or point you want the crowd to gather around.

      5. In the Minimum Distance box, specify the minimum distance between a member of the crowd and the object.

      6. Click OK.


        image

    8. Crowd in Front of Entity

      Human and Crowd Tasks — Disperse Crowd

      The Crowd in Front of Entity task causes a crowd to gather in front of an entity, where the front of the entity is determined based on its heading.

      To cause a crowd to crowd in front of an entity:

      1. Select the crowd.

      2. Choose Task Movement Crowd in Front of Entity. The Crowd in Front of Entity dialog box opens.

      3. Select the entity you want the crowd to gather in front of.

      4. Click OK.


    9. DI-Guy Animation

      VR-Forces can specify the movements and appearance of DI-Guy models used in the Stealth observer mode and in 3D visualization programs such as VR-Vantage Stealth. The DI-Guy Animation task directs the 3D model to engage in a one-time or repeated series of motions. VR-Forces does not simulate the actions that the 3D model performs; it just adjusts the location and orientation of the VR-Forces entity to synchronize it with the 3D model’s animated behavior. To change a 3D model’s appearance, use the DI-Guy Appearance set data request. For details, please see “DI-Guy Characteristics (Appearance, Head, Body Weight),” on page 34-16.


      image

      i The DI-Guy Animation task applies only to lifeform entities.

      image

      To specify a DI-Guy animation:

      1. Select the lifeform entity whose behavior you want to animate.

      2. Choose Task DI-Guy DI-Guy Animation. The DI-Guy Animation dialog box opens.

      3. In the Animation list, select an animation.

      4. In the Animate group box, specify the duration of the animation.

      5. Click OK.


    10. Disperse Crowd

      The Disperse Crowd task causes a crowd to wander freely.

      To disperse a crowd:

      1. Select the crowd.

      2. Choose Task Movement Disperse Crowd.

        Human and Crowd Tasks — Flee from Entities

        image

    11. Flee from Entities

      The Flee from Entities task causes a human entity to flee from a specified entity. It flees until it is a specified distance away. This task can be assigned to individual humans and to crowds. The entities must be within a navigation area.

      To assign a Flee from Entities task:

      1. Select the entity.

      2. Choose Task Movement Flee From Entities. The Flee From Entities dialog box opens.

      3. Select the entity that you want this entity to flee from.

      4. Optionally, specify the radius of the flight zone.

      5. Click OK.


    12. Open Door

      If a human is within approximately one meter of a closed door, this task causes the door to open. This task applies to doors controlled by switch nodes in the terrain, not articu- lated parts.

      To open a door:

      1. Move a human to within one meter of a closed door.

      2. Choose Task Terrain Open Door.


    13. Open Window

      If a human is within approximately one meter of a closed window, this task causes the window to open. This task applies to windows controlled by switch nodes in the terrain, not articulated parts.

      To open a window

      1. Move a human to within one meter of a closed window.

      2. Choose Task Terrain Open Window.


        image

    14. Protest Around Location

      Human and Crowd Tasks — Wander

      The Protest Around Location task causes a crowd to gather around a specified location and continuously execute a series of protest animations.

      To cause a crowd to protest around a location:

      1. Select the crowd.

      2. Choose Task Movement Protest. The Protest Around Location dialog box opens.

      3. Specify a location.

      4. Click OK.


    15. Protest Along Line

      The Protest Along Line task causes a crowd to gather along a specified line and contin- uously execute a series of protest animations.

      To cause a crowd to protest along a line:

      1. Select the crowd.

      2. Choose Task Movement Protest Along Line. The Protest Along Line dialog box opens.

      3. Specify a line.

      4. Specify which side of the line to protest on.

      5. Click OK.


    16. Wander

      The Wander task causes a lifeform entity to move to a series of randomly chosen loca- tions for the specified amount of time. You can constrain wandering to a specified area. If the entity is using a preferred navigation mode and there is preferred road data for the terrain, the Wander task will only choose destinations that meet the preference criteria. The entity must be in a navigation area.

      To assign a Wander task:

      1. Select the entity.

      2. Choose Task Movement Wander. The Wander dialog box opens.

      3. Select a Duration option – Indefinitely or Timed. If you select Timed, specify the amount of time to wander in days, hours, minutes, and seconds.

      4. Select a Movement options – Free or Restricted To Area. If you select Restricted To Area, type the name of an area or select it in the list or on the map.

      5. Click OK.

        Human and Crowd Tasks — Wander In Area

        image

    17. Wander In Area

      The Wander In Area task causes a crowd to wander in the specified area. The entity must be in a navigation area.

      To assign a crowd to wander:

      1. Select the crowd.

      2. Choose Task Movement Wander In Area. The Wander In Area dialog box opens.

      3. Select the area to wander in.

      4. Click OK.


image

30. Embarkation, Wait, Radio, and Other Tasks


This chapter describes the tasks supplied with VR-Forces that are categorized as Embar- kation, Radio, Wait, Other, and uncategorized.

Embarkation Tasks 30-3

Disembark 30-3

Disembark All 30-3

Embark 30-4

Radio Tasks 30-7

Send Radio Set 30-7

Send Radio Task 30-9

Send Text Message 30-10

Wait Tasks 30-10

Wait 30-10

Wait Duration 30-11

Wait Elapsed 30-11

Tasks for Moving Articulated Parts 30-11

Close Cargo Door 30-11

Deploy Refueling Boom 30-12

Lower Periscope 30-12

Open Cargo Door 30-13

Raise Periscope 30-13

Stow Refueling Boom 30-13

Embedded Entity Tasks 30-14

Deploying Embedded Entities 30-14

Recovering Deployed Entities 30-14

Sector Search Operation 30-15

Deploying an Entity with a Task 30-16

image

Embarkation, Wait, Radio, and Other Tasks

Deploy Sonobuoy 30-17

Deploy Sonobuoys Along Route 30-17

Sonar Dip 30-18

User Task 30-18

Reactive Tasks 30-19

    1. Embarkation Tasks

      This section describes tasks for simulating embarking and disembarking. Simulation objects move to the parent simulation object to embark, and move away after disem- barking. For immediate embarkation and disembarkation, use the Embarked and Disembarked set data requests or the embarkation commands on the Objects menu. For a conceptual discussion of embarkation, please see “Embarking and Disembarking Simulation Objects,” on page 19-7.


      1. Disembark

        The Disembark task causes a simulation object to move to the parent simulation object’s egress (exit) point and disembark. If the selected simulation object is a unit (disaggregated), the disembark task is given to all embarked subordinates. The task is considered complete when all subordinates are disembarked. To disembark simulation objects immediately, that is, without using a task, please see “Embarking and Disem- barking Simulation Objects,” on page 19-7.


        image

        i

        i

        • When a simulation object disembarks, it simply goes to the disembarka- tion location. If you plan to disembark several simulation objects from the same parent by giving them disembark tasks, you are responsible for making sure that each simulation object moves from the disembarkation point before the next simulation object disembarks.

        • Units in the aggregated state cannot embark or disembark. If a disaggre- gated unit is embarked, you cannot aggregate it either manually, or as a result of automated aggregation conditions.


          image


          To disembark a simulation object:

          1. Select the simulation object you want to disembark.

            image

          2. Choose Task Embarkation Disembark, or click the Disembark button ( ) on the Last Selected Object Panel or the Tasks Toolbar.


      2. Disembark All

        The Disembark All task is given to a parent simulation object. It gives a Disembark task to all embarked simulation objects except aggregates. When you issue a Disembark All task, VR-Forces tries to disembark the simulation objects sequentially and have them move to sufficiently dispersed locations to avoid collision problems.

        To disembark all simulation objects from a parent simulation object:

        1. Select the parent simulation object.

        2. Choose Task Embarkation Disembark All.


      3. Embark

The Embark task causes a simulation object to move to the ingress (entry) point of the parent simulation object and embark on it. If the embarking simulation object is a unit, each available taskable subordinate is given an embark task. When all subordinates have embarked, the task is considered complete.


image

i Units in the aggregated state cannot embark or disembark.

image

The Embark task is valid only if the specified parent simulation object is configured to accept the simulation object that wants to embark on it. If you task a simulation object to embark on a simulation object that is not configured to receive it, for example, you task a DI to embark on an M1A2, the simulation object will not respond to the task. If you want to embark a simulation object on a simulation object that is not configured to receive it, you can use the immediate embarkation process. For details, please see “Embarking and Disembarking Simulation Objects,” on page 19-7.

Table 30-1 lists the simulation entities that support embarkation that have slots config- ured and the number and type of embarked entities they can hold. (Other simulation objects may support embarkation, but not have slots configured. Slots for humans represent passengers only, not crew members.) High fidelity entities (HF column) have polygonal models of the entity and embarkation slots defined in such a way that the embarking entities can smoothly embark on the host entity when viewed in the 3D view or VR-Vantage.

image

Table 30-1: Embarkation support


Entity Can Carry HF

Entity Can Carry HF

AH-6 Little Bird 1 human

Aircraft Carrier 12 fighters or 9 fighters and 2 cargo x planes. Three helicopters. 70 planes below deck.

Arleigh Burke-class Destroyer 1 aircraft

Bell 206 Jet Ranger 4 humans

Bell 406 6 humans

BMP-2 AFV 7 humans

BTR-80 Armored\ Personnel Carrier 7 humans

C-5 Galaxy 73 humans or 3 ground vehicles

C-130 Hercules 92 humans or 3 ground vehicles

C-17 Globemaster 134 humans or 3 ground vehicles

CH-46E Sea Knight 11 humans

CH-47 Chinook 55 humans

image


Table 30-1: Embarkation support


Entity

Can Carry

HF

CH-53E Super Stallion

55 humans

EC 145

9 humans

Fire Engine

6 humans

GAZ-69 Utility Vehicle

4 humans

Guided Missile Destroyer

2 helicopters

CH-47 Chinook

55 humans

HMMWV (all types)

4 humans

x

LCAC

9 HMMWVs or 4 trucks or 1 M1A2 or 1 generic ground vehicle

LSD-49 Harpers Ferry

2 LCACs and 2 helicopters

x

M-939A2 5-Ton Truck

14 humans

x

M1126 Stryker ICV

9 humans

M113 Armored Utility Vehicle

11 humans

M2A2 Bradley IFV

6 humans

M939A2 5-Ton Truck

14 humans

MD500

4 humans

MH-47 Chinook

55 humans

MH-6 Little Bird

1 human

MH-60 Blackhawk

11 humans

MH-60L Blackhawk DAP

11 humans

Mi-2 Hoplite

8 humans

MT-LB Multipurpose Armored Vehicle

11 humans

Nimitz Class Carrier

48 aircraft, including fighter jets, helicopters, and reconnaissance.

OH-58 Kiowa

1 human

P-3 Orion

11 humans

Rigid Hull Inflatable Boat

8 humans

Rigid Hull Inflatable Boat - Civilian

6 humans

SH-60 Seahawk

11 humans

Space Shuttle

7 humans

Technical Truck

4 humans

Tractor Trailer Cab

2 humans

Tractor Trailer with Cab

2 humans

UH-60 Blackhawk

11 humans


image

Table 30-1: Embarkation support


Entity Can Carry HF

Entity Can Carry HF

UH-72 Lakota 9 humans

    1. Osprey 24 humans, 1 light ground vehicle

      VAB APC 10 humans

      image


      The aircraft carrier can carry both fixed-wing and rotary-wing aircraft. After the deck positions are used, additional entities embarked are stored below deck, as in a low- fidelity model.


      image

      !

      !

      • If you are using HLA and want to use the embarkation feature, you must use RPR FOM 2, draft 17 or later.

      • If the embarkation spaces on the parent simulation object are full, VR- Forces sends a message to the back-end console and the simulation object does not try to embark.

      • If you give multiple simulation objects embark tasks for the same parent, you are responsible for spreading the tasks over time so that the simula- tion objects do not all converge on the parent at the same time, which would result in problems due to collision avoidance.

      • A simulation object is considered embarked as soon as it reaches its ingress point. In plan view mode, its icon is hidden immediately. However, in a 3D mode, the simulation object may need to continue moving to reach its slot on the parent. If you task the parent simulation object to move before a simulation object has moved to its slot, the embarking 3D model may end up in an odd position relative to the parent simulation object. To avoid this visual problem, allow time for the embarking simulation object to stop moving before the parent entity moves.


image


To embark a simulation object:

  1. Select the simulation object .

    image

  2. Choose Task Embarkation Embark, or click the Embark button ( ) on the Last Selected Object Panel or the Tasks Toolbar. The Embark On dialog box opens.


    image

    i

    i

    Unlike the Embark On dialog box that opens when you choose Objects Embark, the Embark On dialog box for the Embark task does not allow you to choose the embarkation point.


    image


  3. Select the parent simulation object (the simulation object to embark on) or type its name in the Name box.

  4. If the parent simulation object has slots of a specific type and you want the simula- tion object to embark in a slot of a particular type, select the type in the Slot Type list. Slots of that type are now listed in the Slot Name list. (For information about slot types and slot names, please see “Configuring Embarkation,” on page 65-34 and “Configuring Slots,” on page 65-38.)

  5. Select a slot from the Slot Name list.

  6. If you want the simulation object to use any available slot, select the Choose Any Slot if Requested Slot Not Available check box.

  7. Click OK.


    1. Radio Tasks

      This section describes the tasks that let you use the VR-Forces radio network to send messages, tasks, and set data requests.


      1. Send Radio Set

        The Send Radio Set task lets you send a set data request to a simulation object using a VR-Forces radio message. The receiving entity executes the set data request as if you had issued it directly to the entity from the Set menu or a set data request in a plan.


        image

        i

        i

        Since VR-Forces has no idea what type of entity you might want to give a set data request to, when you add this task the full list of possible sets is available. There is no context sensitivity like there is when you select a simulation object and view the Set menu. It is up to you to be sure that the set you are assigning to a simulation object is supported by that object type.


        image

        Embarkation, Wait, Radio, and Other Tasks — Radio Tasks

        image


        To send a set data request radio message:

        1. Select the simulation object that will send the message.

        2. Choose Task Radio Send Radio Set. The Send Radio Set dialog box opens.

        3. To send the message to all simulation objects configured to receive messages from this simulation object’s radio, select the Broadcast check box. (For details about configuring the radio model, please see “Configuring Radios,” on page 74-4.)

          To send the message to a specific simulation object, in the Send Set To group box, in the Name text box, type the name of the simulation object that will receive the set data request message, or select the simulation object in the list or on the terrain.

          A list of set data requests is displayed (Figure 30-1).


          image

          Figure 30-1. Send Radio Set dialog box

        4. Select the set data request you want to send.

        5. Click OK. If the set data request requires input, an appropriate dialog box opens. If no input is required, the task setup is finished.

        6. If a dialog box opens, complete the dialog box as described in Chapter 34, Setting the State of Simulation Objects.

        7. Click OK.


      2. Send Radio Task

        The Send Radio Task task lets you send a task to a simulation object using a VR-Forces radio message. The receiving simulation object executes the task as an independent task.


        image

        i

        i

        Since VR-Forces has no idea what type of simulation object you might want to give a task to, when you add this task the full list of possible tasks is available. There is no context sensitivity like there is when you select a simulation object and view the Task menu. It is up to you to be sure that the task you are assigning to a simulation object is supported by that object type.


        image


        To send a task radio message:

        1. Select the simulation object that will send the message.

        2. Choose Task Radio Send Radio Task. The Send Radio Task dialog box opens.

        3. To send the message to all simulation objects configured to receive messages from this simulation object’s radio, select the Broadcast check box. (For details about configuring the radio model, please see “Configuring Radios,” on page 74-4.)

          To send the message to a specific simulation object, in the Send Task To group box, in the Name text box, type the name of the simulation object that will receive the task message, or select the simulation object in the list or on the terrain.

          A list of tasks is displayed (similar to Figure 30-1).

        4. Select the task you want to send.

        5. Click OK. If the task requires input, an appropriate dialog box opens. If no input is required, the task setup is finished.

        6. If a dialog box opens, complete the dialog box as described in Chapter 34, Setting the State of Simulation Objects.

        7. Click OK.

          Embarkation, Wait, Radio, and Other Tasks — Wait Tasks

          image

      3. Send Text Message

        The Send Text Message task lets you send a text message to a simulation object using a VR-Forces simulated radio message. The receiving simulation object must be on the same network as the sending simulation object. Usually this means the same unit or same force. The receiving simulation object can test for receipt of the message in a conditional statement in its plan. (For details, please see “Receive Text Message,” on page 35-13.)

        To send a text message:

        1. Select the simulation object that will send the message.

        2. Choose Task Radio Send Text Message. The Send Text dialog box opens.

        3. To send the message to all simulation objects configured to receive messages from this simulation object’s radio, select the Broadcast check box. (For details about configuring the radio model, please see “Configuring Radios,” on page 74-4.)

          To send the message to a specific simulation object, in the Name text box, type the name of the simulation object that will receive the task message, or select the simu- lation object in the list or on the terrain.

        4. In the Message Text box, type the message.

        5. Click OK.


    1. Wait Tasks

      You can order a simulation object to wait indefinitely, for a specified period of time, or until a specified elapsed simulation time.


      image

      i

      i

      The Wait task is not equivalent to an immediate stop task. If a simulation object is moving and you give it a Wait task, it might not stop immediately, particularly if a controller such as the collision avoidance controller is controlling its movement.


      image


      1. Wait

        To order a simulation object to wait indefinitely:

        1. Select the simulation object.

        2. Choose Task Wait Wait.


          image

          i

          i

          If you put an indefinite wait in a plan, the simulation object does not progress through its plan until it receives another command.


          image


      2. Wait Duration

        To order a simulation object to wait a specific amount of time:

        1. Select the simulation object.

        2. Choose Task Wait Wait Duration. The Wait Duration dialog box opens.

        3. Specify the duration of the wait in hours, minutes, and seconds.

        4. Click OK.


      3. Wait Elapsed

        To order a simulation object to wait until a specific elapsed simulation time:

        1. Select the simulation object.

        2. Choose Task Wait Wait Elapsed. The Wait Elapsed dialog box opens.

        3. Specify the elapsed time from the start of the simulation, in hours, minutes, and seconds.

        4. Click OK.

          For information about simulation time and simulated exercise time, please see “Simula- tion Time,” on page 3-10.


    2. Tasks for Moving Articulated Parts

      Some entity models have articulated parts, such as doors and periscopes, that you can move.


      1. Close Cargo Door

        The Close Cargo Door task closes a cargo door on an entity that has a cargo door artic- ulated part.

        To close a cargo door:

        1. Select the entity.

        2. Choose Task Cargo Door Close Cargo Door.

          Embarkation, Wait, Radio, and Other Tasks — Tasks for Moving Articulated Parts

          image

      2. Deploy Refueling Boom

        The Deploy Refueling Boom task causes an aircraft that has a refueling boom articu- lated part to extend it (Figure 30-2). Use Stow Refueling Boom (“Stow Refueling Boom,” on page 30-13) to retract the boom.



        image

        Figure 30-2. KC-135 Stratotanker with refueling boom deployed

        To deploy a refueling boom:

        1. Select the entity.

        2. Choose Task Refueling Boom Deploy Refueling Boom. The boom is extended.


      3. Lower Periscope

        The Lower Periscope task lowers the periscope of a subsurface entity. The periscope is an articulated part that is visible in the Stealth view.

        To lower a submarine’s periscope:

        1. Select the entity.

        2. Choose Task Other Lower Periscope.


      4. Open Cargo Door

        The Open Cargo Door task opens a cargo door on an entity that has a cargo door artic- ulated part.


        image

        Figure 30-3. CH-53E Super Stallion with open cargo door

        To open a cargo door:

        1. Select the entity.

        2. Choose Task Cargo Door Open Cargo Door.


      5. Raise Periscope

        The Raise Periscope task raises the periscope of a subsurface entity. The periscope is an articulated part that is visible in the Stealth observer mode.

        To raise a submarine’s periscope:

        1. Select the entity.

        2. Choose Task Other Raise Periscope.


      6. Stow Refueling Boom

        The Stow Refueling Boom task causes an aircraft that has a refueling boom articulated part to stow it. Use Deploy Refueling Boom (“Deploy Refueling Boom,” on

        page 30-12) to deploy a refueling boom.

        To stow a refueling boom:

        1. Select the entity.

        2. Choose Task Refueling Boom Stow Refueling Boom. The boom contracts.


    3. Embedded Entity Tasks

      You can deploy and recover embedded entities. You can also task an embedded entity to conduct a sector search. For details about embedded entities, please see “Embedded Entities,” on page 19-12.


      image

      1. Deploying Embedded Entities

        To add an embedded entity to a simulation, you deploy it from the parent entity.

        You can deploy an embedded entity explicitly or implicitly (by assigning a task to it). An embedded entity’s label displays its name and the name of its parent.


        image

        i

        i

        There is a delay of a few seconds from the time a deployment is ordered and the time it is executed.


        image


        To deploy an embedded entity explicitly:

        1. Select the parent entity.

        2. Choose Task Embedded Entity Deploy. The Deploy dialog box opens.

        3. Select the entity you want to deploy.

        4. Click OK. The embedded entity gets deployed next to the parent entity in the rela- tive position in its configuration.


          image

      2. Recovering Deployed Entities

        If you want an embedded entity that has been deployed to return to its parent, you can have the parent recover it. If you do not recover it, the deployed entity continues to function in the scenario just like any other entity.

        To recover a deployed embedded entity:

        1. Select the parent entity.

        2. Choose Task Embedded Entity Recover. The Recover Embedded Entity dialog box opens.

        3. Select the entity you want to recover.

        4. Click OK. The parent sends a message to the deployed entity to return. It returns and is embedded again.

          Embarkation, Wait, Radio, and Other Tasks — Embedded Entity Tasks

          image

      3. Sector Search Operation

        The Sector Search Operation task causes an embedded entity to fly a sector search and rescue pattern. In addition to the basic search and rescue parameters, you have the following options:

        • If there are no undeployed embedded entities available, divert an already deployed entity to do the search.

        • Force the parent entity to wait until the search is complete and the embedded entity is recovered until it continues with its plan or allow the parent entity to continue with its plan while the search is underway.

        To execute a sector search operation:

        1. Choose an entity that has embedded entities.

        2. Choose Task Sector Search Operation. The Sector Search Operation dialog box opens.

        3. Select the Allow Diversion check box if you want a deployed entity to be diverted to this task if necessary.

        4. Select the Recover When Finished check box if you want the parent entity to wait until it recovers the deployed entity before it continues with its plan.

        5. Specify the starting point of the search.

        6. In the Leg box, specify the length of each leg of the search.

        7. In the Altitude box, specify the altitude the search aircraft should fly at.

        8. In the Air Speed box, specify the speed of the search aircraft.

        9. Click OK.


      4. Deploying an Entity with a Task

        You can assign a task to a deployable entity, that is, an embedded entity that has not been deployed yet. This implicitly deploys the entity so that it can execute the task. You can assign a task to an embedded entity in the parent’s plan or you can assign a task to a parent entity that requires it to deploy an embedded entity. The Sector Search example scripted task is an example of how to task a parent entity to deploy an embedded entity.


        image

        i

        i

        There is a delay of a few seconds from the time a deployment is ordered and the time it is executed.


        image


        To assign a task to a deployable entity in a parent’s plan:

        1. Select the parent entity.

        2. Choose Objects Plan. The Plan window opens.

        3. Choose Embedded Entities entity Task (or Set) task (or set), where entity is one of the entities that the parent can deploy and task (or set) is one of the tasks or sets on the Task or Set menu. An appropriate dialog box for the task or set opens.


          image

          i

          i

          If an entity does not have embedded entities, the Embedded Entities menu is not available.


          image


        4. Fill out the dialog box like you would for any task or set.

        5. Click OK. The task is added to the plan. When you run the scenario, the embedded entity gets deployed and is assigned the task or set.

Embarkation, Wait, Radio, and Other Tasks — Deploy Sonobuoys Along Route

image

    1. Deploy Sonobuoy

      The Deploy Sonobuoy task lets an aircraft deploy a sonobuoy for taking sonar readings. A sonobuoy is deployed as an entity. This task is available to entities that have a Sonobuoy Deployer system configured.


      image

      i

      i

      RPR FOM 1.0 does not support active sonar. You will not be able to create sonobuoys if they have an active sonar system.


      image


      To deploy a sonobuoy:

      1. Select the entity.

      2. Choose Task Deploy Sonobuoy. The Deploy Sonobuoy dialog box opens.

      3. Select the type of sonar to use – Active or Passive.

      4. Specify the depth at which to deploy the sonobuoy.

      5. Click OK.


    2. Deploy Sonobuoys Along Route

      The Deploy Sonobuoys Along Route task lets an aircraft deploy sonobuoys as it moves along a route. A sonobuoy is deployed as an entity. This task is available to entities that have a Sonobuoy Deployer system configured.


      image

      i

      i

      RPR FOM 1.0 does not support active sonar. You will not be able to create sonobuoys if they have an active sonar system.


      image


      To deploy sonobuoys along a route:

      1. Select the entity.

      2. Choose Task Deploy Sonobuoys Along Route. The Deploy Sonobuoys Along Route dialog box opens.

      3. Select the route to use.

      4. Specify the distance between each sonobuoy.

      5. Select the type of sonar to use – Active or Passive.

      6. Specify the depth at which to deploy the sonobuoys.

      7. Click OK.

        Embarkation, Wait, Radio, and Other Tasks — Sonar Dip

        image

    3. Sonar Dip

      Rotary-wing entities that have sonar can dip the sonar into water at a specified depth. Dipped sonar is not visualized in the Stealth view. The sonar is just simulated at the specified depth. Entities cannot dip sonar if they are moving faster than a set speed.

      To dip sonar:

      1. Select the entity.

      2. Choose Task Sonar Dip. The Sonar Dip dialog box opens.

      3. Specify the location at which to dip the sonar.

      4. Specify how long the sonar should stay dipped.

      5. Select the type of sonar to dip – Active or Passive.


        image

        i RPR FOM 1.0 does not support active sonar.

        image

      6. Specify the depth for the sonar.

      7. Click OK.


    4. User Task

      User tasks are tasks that have been added to VR-Forces using the VR-Forces toolkit. To assign a user task, you must know the name of the task and the required values for up to four parameters.


      image

      i

      i

      The User Task command is not available on the Task menu unless a developer adds a controller that accepts a user task.


      image


      To assign a user task:

      1. Select the simulation object that you want to execute the task.

      2. Choose Task Other User Task. The User Task dialog box opens.

      3. Type the name of the task.

      4. Type any required parameters.

      5. Click OK.


        image

    5. Reactive Tasks

Embarkation, Wait, Radio, and Other Tasks — Reactive Tasks

Reactive tasks are not listed individually because they run automatically; no user action is required to execute them. This section describes the reactive tasks included with VR- Forces.

Table 30-2 lists the reactive tasks provided with VR-Forces.

image

Table 30-2: Reactive tasks


Reactive Task Description

Reactive Task Description

Automatic Headlights Turn headlights and taillights on and off based on local

lighting conditions.

Auto-Enable Show Terrain Turns on Show Terrain task for object upon creation.

Avoid Other Ships Considers ship type: Aircraft carrier is higher than

fishing boat (assumes nets are out), which is higher than sailboat, which is higher than other. Will avoid surfaced submarines.

Bingo Fuel Monitor Monitors fuel on embedded entities and requests a

recovery when bingo fuel level is reached.

Evade Missile Causes fixed-wing entities to try to evade missiles. Flee From Entity Types Flees objects that match the configured entity types.

Flee From Explosion Entity will run from explosions within the specified

range.

Make Way for Emergency If an emergency vehicle that has its lights on

approaches a ground vehicle that is driving on a road, the vehicle pulls over to the side of the road.

Suppressed Crouch Forces entity to crouch when suppressed. Returns to

previous posture when no longer suppressed. Does not otherwise interrupt movement.

Suppressed Prone Forces the entity to stop and fall prone when

suppressed to level 2 or 3. Resumes movement at old posture when no longer suppressed.

image

Embarkation, Wait, Radio, and Other Tasks — Reactive Tasks

image


image 31. Tasks for Aggregate- Level Scenarios


This chapter describes tasks that apply to aggregate-level scenarios.

Introduction to Aggregate-Level Tasks 31-4

Activate Jammer 31-4

Air-to-Ground Attack 31-4

Attack by Fire 31-5

Attack with Anti-Air Missile 31-5

Attack with Anti-Ship Missile 31-5

Attack with Land-Attack Missile 31-6

Attack with Torpedo 31-6

Automatic Air Defense 31-6

Biological Attack 31-7

Bomb Location 31-8

Breach Obstacles 31-9

Change MOPP Level 31-10

Change Posture 31-11

Chemical Attack 31-11

Construct Abatis 31-12

Construct Anti-Tank Ditch 31-13

Construct Barbed Wire 31-14

Construct Barricade 31-14

Construct Berm 31-15

Construct Booby Trap 31-15

Construct Bridge 31-17

image

Tasks for Aggregate-Level Scenarios

Construct Dry Gap 31-18

Construct Fortified Area 31-19

Construct Fortified Line 31-20

Construct Minefield 31-21

Construct Strong Point 31-22

Deactivate Jammer 31-22

Destroy Bridge 31-23

Destroy Ditch 31-23

Destroy Explosive 31-23

Destroy Fortification 31-24

Destroy Obstacle 31-24

Disembark 31-24

Disembark All 31-24

Embark 31-24

FASCAM 31-25

Halt Movement 31-25

Improve Booby Trap 31-25

Improve Breach 31-26

Improve Bridge 31-26

Improve Ditch 31-26

Improve Fortification 31-27

Improve Obstacle 31-27

Indirect Fire 31-28

Move Along Route 31-29

Move Along Route Retrograde 31-29

Move to Location 31-29

Move to Location Retrograde 31-29

Move To Waypoint 31-29

Move to Waypoint Retrograde 31-29

Nuclear Attack 31-30

Patrol Route 31-30

Patrol Between 31-30

Send NBC Report 31-30

Send Obstacle Report 31-31

Send Radio Set 31-31

image

Tasks for Aggregate-Level Scenarios

Send Radio Task 31-31

Send Text Message 31-31

User Task 31-31

Wait Tasks 31-31

Background Process List 31-32

Tasks for Aggregate-Level Scenarios — Introduction to Aggregate-Level Tasks

image

    1. Introduction to Aggregate-Level Tasks

      This chapter describes tasks that simulation objects in aggregate-level scenarios can run. A few tasks are identical to tasks supported by simulation objects in entity-level scenarios.


    2. Activate Jammer

      The Activate Jammer task turns on jamming for a simulation object equipped with a jamming emitter. This task has the same effect as Set Emitter - On.

      To activate a simulation object’s jammer, choose Task Jamming Activate Jammer.


    3. Air-to-Ground Attack

      The Air-to-Ground Attack task requires an attack (ingress) route, an exit (egress) route, and a target point.

      When the aircraft reaches the target point, it attacks with each type of HE ammunition it has. It expends all ammunition of each type. There is a 30 second delay between attacks with each ammunition type.

      To specify an air-to-ground attack:

      1. Select the entity that will attack.

      2. Choose Task Engagement Air-to-Ground Attack. The Air-to-Ground Attack dialog box opens.

      3. Select a target point.

      4. Select an ingress route.

      5. Select an egress route.


        image

        i

        i

        This is a multiple list dialog box. For details about how to control which list has focus, please see “Selecting Objects in Multiple List Dialog Boxes,” on page 26-8.


        image


      6. Click OK.

        Tasks for Aggregate-Level Scenarios — Attack with Anti-Ship Missile

        image

    4. Attack by Fire

      The Attack By Fire task is for use by units created by aggregating multiple units. When assigned, the units move to the specified location. Armor and mechanized units are placed towards the front of the unit. Artillery is placed in the rear. Other units are placed between the forward and rear simulation objects. When the unit is in position, artillery begins indirect fire on the target and the other units engage any enemy simula- tion objects that are in range.

      To order attack by fire:

      1. Select the unit.

      2. Choose Task Engagement Attack By Fire. The Attack By Fire dialog box opens.

      3. Specify the location of the target entity.

      4. Specify a location for the attacking unit.

      5. Click OK.


    5. Attack with Anti-Air Missile

      This task is available to any simulation object that has anti-air missiles.

      To attack a unit with an anti-air missile:

      1. Select the simulation object that will attack.

      2. Choose Task Engagement Attack with Anti-Air Missile. The Attack with Anti- Air Missile dialog box opens.

      3. Select a target.

      4. Specify the number of missiles to fire.

      5. Click OK.


    6. Attack with Anti-Ship Missile

      This task is available to any simulation object that has anti-ship missiles.

      To attack a unit with an anti-ship missile:

      1. Select the simulation object that will attack.

      2. Choose Task Engagement Attack with Anti-Ship Missile. The Attack with Anti-ship Missile dialog box opens.

      3. Select a target.

      4. Specify the number of missiles to fire.

      5. Click OK.

        Tasks for Aggregate-Level Scenarios — Attack with Land-Attack Missile

        image

    7. Attack with Land-Attack Missile

      This task is available to entities that have land-attack missiles, such as the Arleigh Burke DDG.

      To attack a unit with a land-attack missile:

      1. Select the simulation object that will attack.

      2. Choose Task Engagement Attack with Land-Attack Missile. The Attack with Land-Attack Missile dialog box opens.

      3. Select a target.

      4. Specify the number of missiles to fire.

      5. Click OK.


    8. Attack with Torpedo

      This task is available to entities that have torpedoes, such as the Arleigh Burke DDG.

      To attack a unit with a torpedo:

      1. Select the entity that will attack.

      2. Choose Task Engagement Attack with Torpedo. The Attack with Torpedo dialog box opens.

      3. Select a target.

      4. Specify the number of torpedoes to fire.

      5. Click OK.


    9. Automatic Air Defense

      When a simulation object has the Automatic Air Defense task, it automatically fires at enemy aircraft that enter the specified area. A simulation object must have an anti-air weapon, such as air-to-air missile to execute this task.

      To enable automatic air defense:

      1. Select a simulation object that has anti-air capability.

      2. Choose Task Engagement Automatic Air Defense. The Automatic Air Defense dialog box opens.

      3. Select the area in which the simulation object should automatically fire anti-air weapons.

      4. Click OK.


        image

    10. Biological Attack

      Tasks for Aggregate-Level Scenarios — Biological Attack

      The Biological Attack task lets a simulation object create an area contaminated with biological agents.

      When you assign a Biological Attack task, you specify the center of the area in which it will take place. The size of the area and the allowed range from the simulation object is specified in the biological weapon weapon system. You can edit these values in the Simulation Object Editor.

      To execute a biological attack:

      1. Select the simulation object that will make the attack.

      2. Choose Task Engagement Biological Attack. The Biological Attack dialog box opens.

      3. Click a location for the center of the area of attack or specify the coordinates.

      4. In the Agent Type list, select the type of biological agent.

      5. Click OK.

        Tasks for Aggregate-Level Scenarios — Bomb Location

        image

    11. Bomb Location

      You can specify that a simulation object bomb a location. When you choose a weapon, the Bomb Location dialog box displays information about the chosen weapon (Figure 31-1).


      image

      Figure 31-1. Bomb Location dialog box

      To bomb a location:

      1. Select the simulation object that will attack.

      2. Choose Task Engagement Bomb Location. The Bomb Location dialog box opens.

      3. Click the location to bomb or enter the coordinates.

      4. Specify the number of bombs to drop.

      5. In the Weapon list, select the type of bomb to drop.

      6. Click OK.


        image

    12. Breach Obstacles

      Tasks for Aggregate-Level Scenarios — Breach Obstacles

      The Breach Obstacles task lets an engineering unit breach an obstacle so that units can pass through it. Depending on the breaching system a unit has, it may be able to breach fortifications, minefields, or ditches.

      A breach line is specified with two points.

      To breach an obstacle:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Breach Obstacles. The Breach Obstacles dialog box opens.

      3. Click Define. The cursor changes to draw mode and the Create Breach dialog box opens or becomes available.

      4. Draw a two-point line to specify where to create the breach. After the second click the line disappears. This is because it is not being created now. The dialog box button now says Edit and the text next to it says Defined.

      5. Click OK.

        Tasks for Aggregate-Level Scenarios — Change MOPP Level

        image

    13. Change MOPP Level

      Units automatically raise their mission oriented protective posture (MOPP) level when they encounter a contamination area. However, you can manually change a unit’s MOPP level.

      Supported MOPP levels are as follows:

      • MOPP Level 0 — Protective mask carried. Suit, gloves, and boots accessible/avail- able.

      • MOPP Level 1 — Suit worn. Mask, gloves and boots carried.

      • MOPP Level 2 — Suit and boots worn. Gloves and mask carried.

      • MOPP Level 3 — Suit, boots and mask worn. Gloves carried.

      • MOPP Level 4 — All protection worn.

      Changes to MOPP level do not take place immediately. (To change the MOPP level immediately, use Set MOPP Level.) Increasing the MOPP level degrades a simulation object’s speed and combat effectiveness. Increasing the MOPP level does not remove existing contamination, but prevents most NBC contamination from harming the simulation object.

      To change a unit’s MOPP level:

      1. Select the unit.

      2. Choose Task Change MOPP Level. The Change MOPP Level dialog box opens.

      3. Specify a new MOPP level.

      4. Click OK.


        image

    14. Change Posture

      Tasks for Aggregate-Level Scenarios — Chemical Attack

      You can set a simulation object’s posture to one of the following:

      Changes to posture take place over time. To change posture immediately, use Set Posture.

      To change a simulation object’s posture:

      1. Select the simulation object.

      2. Choose Task Change Posture. The Change Posture dialog box opens.

      3. Specify a new posture.

      4. Click OK.


    15. Chemical Attack

      The Chemical Attack task lets a unit create an area contaminated with chemical agents.

      When you assign a Chemical Attack task, you specify the center of the area in which it will take place. The size of the area and the allowed range from the unit is specified in the chemical weapon weapon system. You can edit this value in the Simulation Object Editor.

      To execute a chemical attack:

      1. Select the unit that will make the attack.

      2. Choose Task Engagement Chemical Attack. The Chemical Attack dialog box opens.

      3. Click a location for the center of the area of attack or specify the coordinates.

      4. In the Agent Type list, select the type of chemical agent.

      5. Click OK.

        Tasks for Aggregate-Level Scenarios — Construct Abatis

        image

    16. Construct Abatis

      Combat engineering units can construct abatises. An abatis is specified as a point.


      image

      i

      i

      You can create abatises directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.


      image


      To construct an abatis:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Abatis. The Construct Abatis dialog box opens (Figure 31-2). The Location is specified as “Not defined”.


        image

        Figure 31-2. Construct Abatis dialog box

      3. Click Define. The Create Abatis dialog box opens (Figure 31-3).


        image

        Figure 31-3. Create Abatis dialog box

      4. Click where you want to locate the abatis.

      5. In the Create Abatis dialog box, click OK.

      6. Optionally, specify a name for the abatis.

      7. In the Construct Abatis dialog box, click OK.

        Tasks for Aggregate-Level Scenarios — Construct Anti-Tank Ditch

        image

    17. Construct Anti-Tank Ditch

      Combat engineering units can construct anti-tank ditches. An anti-tank ditch is a linear object. This task takes place over time.


      image

      i

      i

      You can create anti-tank ditches directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.


      image


      To construct an anti-tank ditch:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Anti-Tank Ditch. The Construct Anti-Tank Ditch dialog box opens (similar to Figure 31-2). The Location is speci- fied as “Not defined”.

      3. Click Define. The Create Anti-Tank Ditch dialog box opens and the cursor changes to draw mode.

      4. Click to specify the vertexes of the line as you would when creating any linear object, or add points in the dialog box and click Create.

      5. Optionally, specify a name for the ditch.

      6. Click OK.

        Tasks for Aggregate-Level Scenarios — Construct Barbed Wire

        image

    18. Construct Barbed Wire

      Combat engineering units can construct barbed wire obstacles. Barbed wire is specified as a line.


      image

      i

      i

      You can create barbed wire directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.


      image


      To construct barbed wire:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Barbed Wire. The Construct Barbed Wire dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Barbed Wire dialog box opens.

      4. Click to specify the vertexes of the line as you would when creating any linear object.

      5. Optionally, specify a name for the barbed wire.

      6. In the Construct Barbed Wire dialog box, click OK.


    19. Construct Barricade

      Combat engineering units can construct barricades. A barricade is specified as a line.


      image

      i

      i

      You can create barricades directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.


      image


      To construct a barricade:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Barricade. The Construct Barri- cade dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Barricade dialog box opens.

      4. Click to specify the vertexes of the line as you would when creating any linear object.

      5. Optionally, specify a name for the barricade.

      6. In the Construct Barricade dialog box, click OK.


        image

    20. Construct Berm

      Tasks for Aggregate-Level Scenarios — Construct Booby Trap

      Combat engineering units can construct berms. A berm is specified as a line.


      image

      i

      i

      You can create berms directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.


      image


      To construct a berm:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Berm. The Construct Berm dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Berm dialog box opens.

      4. Click to specify the vertexes of the line as you would when creating any linear object.

      5. Optionally, specify a name for the berm.

      6. In the Construct Berm dialog box, click OK.


    21. Construct Booby Trap

      Combat engineering entities can construct booby traps. A booby trap is a location where explosives detonate if triggered by the presence of a simulation object. Booby traps cause some level of attrition on the affected simulation object. To create a booby trap, a unit must have explosive resources.


      image

      i

      i

      You can create booby traps directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.


      image


      To construct a booby trap:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Booby Trap. The Construct Booby Trap dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Booby Trap dialog box opens.

      4. Click where you want to locate the booby trap or type the coordinates in the dialog box and click OK.

      5. Optionally, specify a name for the booby trap.

        Tasks for Aggregate-Level Scenarios — Construct Booby Trap

        image


      6. Click OK.


        image

    22. Construct Bridge

      Tasks for Aggregate-Level Scenarios — Construct Bridge

      Combat engineering units can construct bridges. A bridge is specified as a two-point line.


      image

      i

      i

      You can create bridges directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.


      image


      To construct a bridge:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Construct Bridge. The Construct Bridge dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Bridge dialog box opens and the cursor changes to draw mode.

      4. Click on the terrain to specify the start and end vertices of the bridge.

      5. Right-click to finish the bridge, or click Create in the Create Bridge dialog box.

      6. Optionally, specify a name for the bridge.

      7. Click OK.

        Tasks for Aggregate-Level Scenarios — Construct Dry Gap

        image

    23. Construct Dry Gap

      Combat engineering entities can construct dry gaps. A dry gap is a type of ditch. (Use Improve Ditch and Destroy Ditch to continue building a dry gap or destroy it.)


      image

      i

      i

      You can create dry gaps directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.


      image


      To construct a dry gap:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Dry Gap. The Construct Dry Gap dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Dry Gap dialog box opens and the cursor changes to draw mode.

      4. Click to specify the vertices of the dry gap.

      5. Right-click to finish the dry gap, or click Create in the Create Dry Gap dialog box.

      6. Optionally, specify a name for the dry gap.

      7. Click OK.

        Tasks for Aggregate-Level Scenarios — Construct Fortified Area

        image

    24. Construct Fortified Area

      Combat engineering entities can construct fortified areas. A fortified area is defined as a box. You specify the southwest corner of the area. Construction of a fortified area takes place over time.


      image

      i

      i

      You can create fortifications directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.


      image


      To construct a fortified area:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Fortified Area. The Construct Fortified Area dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Fortified Area dialog box opens and the cursor changes to show an area.

      4. Click where you want to locate the southwest corner of the area or type the coordi- nates in the dialog box and click Create.

      5. Optionally, specify a name for the area.

      6. Click OK.

        Tasks for Aggregate-Level Scenarios — Construct Fortified Line

        image

    25. Construct Fortified Line

      Combat engineering entities can construct fortified lines.


      image

      i

      i

      You can create fortifications directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.


      image


      To construct a fortified line:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Fortified Line. The Construct Fortified Line dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Fortified Line dialog box opens and the cursor changes to draw mode.

      4. Click to specify the vertexes of the line as you would when creating any linear object, or add points in the dialog box and click Create.

      5. Optionally, specify a name for the line.

      6. Click OK.

        Tasks for Aggregate-Level Scenarios — Construct Minefield

        image

    26. Construct Minefield

      Combat engineering entities can construct volcano minefields. Minefields are fixed size rectangles.


      image

      i

      i

      You can create minefields directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.


      image


      To construct a minefield:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Minefield. The Construct Mine- field dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Minefield (Volcano) dialog box opens and the cursor changes to show a minefield.

      4. Click where you want to locate the southwest corner of the minefield or type the coordinates in the Create Minefield (Volcano) dialog box and click Create.

      5. Optionally, specify a name for the minefield.

      6. In the Construct Minefield dialog box, click OK.

        Tasks for Aggregate-Level Scenarios — Construct Strong Point

        image

    27. Construct Strong Point

      Combat engineering entities can construct strong points. A strong point is defined as a box. You specify the southwest corner.


      image

      i

      i

      You can create strong points directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.


      image


      To construct a strong point:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Construct Strong Point. The Construct Strong Point dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Strong Point dialog box opens and the cursor changes to show a box.

      4. Click where you want to locate the southwest corner of the box or type the coordi- nates in the dialog box and click Create.

      5. Optionally, specify a name for the strong point.

      6. Click OK.


    28. Deactivate Jammer

      The Deactivate Jammer task turns off jamming for a simulation object equipped with a jamming emitter. This task has the same effect as Set Emitter - Off.

      To deactivate a simulation object’s jammer, choose Task Jamming Deactivate Jammer.


      image

    29. Destroy Bridge

      Tasks for Aggregate-Level Scenarios — Destroy Explosive

      When you task an engineering unit to destroy a bridge, it consumes its Explosives resource. As the unit attacks the bridge, the bridge’s completeness percentage decreases. When the completion percentage reaches zero, the bridge is removed from the scenario.

      To destroy a bridge:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Destroy Bridge. The Destroy Bridge dialog box opens.

      3. Select the bridge you want to destroy.

      4. Click OK.


    30. Destroy Ditch

      When you task an engineering unit to destroy a ditch, it consumes its Explosives resource. As the unit attacks the ditch, the ditch’s completeness percentage decreases. When the completion percentage reaches zero, the ditch is removed from the scenario.

      To destroy a ditch:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Destroy Ditch. The Destroy Ditch dialog box opens.

      3. Select the ditch you want to destroy.

      4. Click OK.


    31. Destroy Explosive

      The Destroy Explosive task lets a unit destroy a booby trap or unexploded ordnance.

      To destroy explosives:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Destroy Explosive. The Destroy Explosive dialog box opens.

      3. Select the booby trap or unexploded ordnance you want to destroy.

      4. Click OK.

        Tasks for Aggregate-Level Scenarios — Destroy Fortification

        image

    32. Destroy Fortification

      When you task an engineering unit to destroy a fortification, it consumes its Explosives resource. As the unit attacks the fortification, the fortification’s completeness percentage decreases. When the completion percentage reaches zero, the fortification is removed from the scenario.

      To destroy a fortification:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Destroy Fortification. The Destroy Fortifi- cation dialog box opens.

      3. Select the fortification you want to destroy.

      4. Click OK.


    33. Destroy Obstacle

      The Destroy Obstacle task lets a unit destroy obstacles (such as berms, barricades, and barbed wire) that do not have a specific destroy task, such as Destroy Fortification or Destroy Explosive.

      To destroy an obstacle:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Destroy Obstacle. The Destroy Obstacle dialog box opens.

      3. Select the obstacle you want to destroy.

      4. Click OK.


    34. Disembark

      For details, please see “Disembark,” on page 30-3.


    35. Disembark All

      For details, please see “Disembark All,” on page 30-3.


    36. Embark

      For details, please see “Embark,” on page 30-4.


      image

    37. FASCAM

      Tasks for Aggregate-Level Scenarios — Improve Booby Trap

      Entities with a FASCAM weapon system, such as artillery, can fire FASCAM (family of scatterable mines).

      To fire FASCAM:

      1. Select a simulation object that can execute this task.

      2. Choose Tasks FASCAM. The FASCAM dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.

      3. Click Define. The Create Minefield (ADAM-RAAM) dialog box opens and the cursor changes to show a minefield.

      4. Click where you want to locate the southwest corner of the minefield or type the coordinates in the Create Minefield (ADAM-RAAM) dialog box and click Create.

      5. Optionally, specify a heading.

      6. In the FASCAM dialog box, click OK.


    38. Halt Movement

      The Halt Movement task causes a simulation object to stop moving.

      To halt a simulation object’s movement:

      1. Select the simulation object.

      2. Choose Tasks Movement Halt Movement. Movement stops immediately.


    39. Improve Booby Trap

      The Improve Booby Trap task lets a combat engineering unit improve an incomplete booby trap. When you improve a booby trap it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is creating a booby trap.

      To improve a booby trap:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Improve Booby Trap. The Improve Booby Trap dialog box opens.

      3. Select the booby trap that you want to improve.

      4. Click OK.

        Tasks for Aggregate-Level Scenarios — Improve Breach

        image

    40. Improve Breach

      The Improve Breach task lets a combat engineering unit improve an incomplete breach. When you improve a breach it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is breaching an obstacle.

      To improve a breach:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Improve Breach. The Improve Breach dialog box opens.

      3. Select the breach you want to improve.

      4. Click OK.


    41. Improve Bridge

      The Improve Bridge task lets a combat engineering unit improve an incomplete bridge. When you improve a bridge it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is creating a bridge.

      To improve a bridge:

      1. Select a combat engineering unit.

      2. Choose Tasks Combat Engineering Improve Bridge. The Improve Bridge dialog box opens.

      3. Select the bridge you want to improve.

      4. Click OK.


    42. Improve Ditch

      The Improve Ditch task lets a combat engineering unit improve an incomplete anti- tank ditch. When you improve a ditch it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is creating a ditch.

      To improve a ditch:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Improve Ditch. The Improve Ditch dialog box opens.

      3. Select the ditch that you want to improve.

      4. Click OK.

        Tasks for Aggregate-Level Scenarios — Improve Obstacle

        image

    43. Improve Fortification

      The Improve Fortification task lets a unit improve an incomplete fortification area, line, or strong point. When you improve a fortification it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is creating a fortification.

      To improve a fortification:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Improve Fortification. The Improve Fortifi- cation dialog box opens.

      3. Select the fortification that you want to improve.

      4. Click OK.


    44. Improve Obstacle

      The Improve Obstacle task lets a unit improve an incomplete obstacle (such as berms, barricades, and barbed wire) that does not have a dedicated improve task, such as Improve Breach or Improve Bridge. When you improve an obstacle it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is constructing an obstacle.

      To improve an obstacle:

      1. Select a combat engineering unit.

      2. Choose Task Combat Engineering Improve Obstacle. The Improve Obstacle dialog box opens.

      3. Select the obstacle that you want to improve.

      4. Click OK.

        Tasks for Aggregate-Level Scenarios — Indirect Fire

        image

    45. Indirect Fire

      The Indirect Fire task allows a simulation object to fire on a point. The indirect fire scatters bursts within a sheaf radius, which is a circle around the target point.

      If multiple units are within the radius, they are all attacked. Attack strength is applied fully to each attacked simulation object. It is not divided among them. For example, if there are four units in the sheaf radius and the attack strength is 100, an attack strength of 100 is applied to each of the units.

      If the blast effect radius of the munitions being fired is less than the sheaf radius, the attack strength is reduced by the ratio of the areas of the blast circle to the sheaf circle. For example, if the sheaf radius is 100 and the blast effect radius is 50, the ratio of the areas is 1:4, so the attack strength would be 25% of the full value.

      To specify indirect fire for a unit:

      1. Select the unit.

      2. Choose Task Engagement Indirect Fire. The Indirect Fire dialog box opens.

      3. Select the point on which you want to center the indirect fire.

      4. In the Weapon list, select the weapon you want to use. Its characteristics are displayed.

      5. In the Number of Attacks box, specify how many attacks to make.

      6. In the Sheaf Radius box, specify the radius, in meters, around which to scatter indi- rect fire. This value must be equal to or less than the Max Sheaf Radius value shown in the Weapon Information group box for the selected weapon.

      7. Click OK.

        Tasks for Aggregate-Level Scenarios — Move to Waypoint Retrograde

        image

    46. Move Along Route

      For details, please see “Move Along Route,” on page 27-13.


    47. Move Along Route Retrograde

      Move Along Route Retrograde is the same as Move Along Route, except that the simu- lation object does not change its heading to the direction of movement. It maintains the heading at the start of movement or a heading necessary for defensive operations. See the Move Along Route task for the procedure for this task.


    48. Move to Location

      For details, please see “Move to Location,” on page 27-16.


    49. Move to Location Retrograde

      Move to Location Retrograde is the same as Move to Location, except that the simula- tion object does not change its heading to the direction of movement. It maintains the heading at the start of movement or a heading necessary for defensive operations. See the Move to Location task for the procedure for this task.


    50. Move To Waypoint

      For details, please see “Move to Waypoint,” on page 27-20.


    51. Move to Waypoint Retrograde

      Move to Waypoint Retrograde is the same as Move to Waypoint, except that the simu- lation object does not change its heading to the direction of movement. It maintains the heading at the start of movement or a heading necessary for defensive operations. See the Move to Waypoint task for the procedure for this task.

      Tasks for Aggregate-Level Scenarios — Nuclear Attack

      image

    52. Nuclear Attack

      The Nuclear Attack task lets a simulation object create an area contaminated with nuclear radiation.

      When you assign a Nuclear Attack task, you specify the center of the area in which it will take place. The size of the area and the allowed range from the simulation object is specified in the nuclear weapon weapon system. You can edit this value in the Simula- tion Object Editor.

      To execute a nuclear attack:

      1. Select the simulation object that will make the attack.

      2. Choose Task Engagement Nuclear Attack. The Nuclear Attack dialog box opens.

      3. Click a location for the center of the attack area or specify the coordinates.

      4. In the Agent Type list, select the type of radiation.

      5. Click OK.


    53. Patrol Route

      For details, please see “Patrol Route,” on page 27-23.


    54. Patrol Between

      For details, please see “Patrol Between,” on page 27-24.


    55. Send NBC Report

      An NBC report is the equivalent of sending a spot report when an NBC area is found. NBC reports are sent automatically if a simulation object has an NBC sensor. However, this task allows you to send a report manually.

      To send an NBC report:

      1. Select a simulation object.

      2. Choose Task Send NBC Report. The Send NBC Report dialog box opens.

      3. Select the contamination area for which to send a report.

      4. Specify the Engagement Result. This is any text that you want to accompany the report.

      5. Click OK.


        image

    56. Send Obstacle Report

      Tasks for Aggregate-Level Scenarios — Wait Tasks

      An obstacle report is the equivalent of sending a spot report when an obstacle area is found. Obstacle reports are sent automatically if a simulation object has an engineering object sensor. However, this task allows you to send a report manually.

      To send an obstacle report:

      1. Select a simulation object.

      2. Choose Task Send Obstacle Report. The Send Obstacle Report dialog box opens.

      3. Select the obstacle for which to send a report.

      4. Specify the Engagement Result. This is any text that you want to accompany the report.

      5. Click OK.


    57. Send Radio Set

      For details, please see “Send Radio Set,” on page 30-7.


    58. Send Radio Task

      For details, please see “Send Radio Task,” on page 30-9.


    59. Send Text Message

      For details, please see “Send Text Message,” on page 30-10.


    60. User Task

      For details, please see “User Task,” on page 30-18.


    61. Wait Tasks

      For details, please see “Wait Tasks,” on page 31-31.

      Tasks for Aggregate-Level Scenarios — Background Process List

      image

    62. Background Process List

Background processes are not described in detail because they run automatically; no user action is required to execute them.

Table 31-1 lists the background tasks provided. These tasks are only available for units in AggregateLevel.sms.

image

Table 31-1: Background processes


Background Process Description

Background Process Description

Attack Enemies Determines when to begin and stop attacking enemies.

Calculate Maximum Speed Modifier

Calculates a modifier that is applied to the maximum possible speed of a unit to modify its movement rate.

Halt When Engaged Stop moving when attacking a hostile simulation object.

Make EW Attack If a jammer system is turned on, attack all non-friendly

simulation objects within range of the jammer. The simu- lation object attacks continuously.

Manage Sensors Manages the state of a simulation object’s sensors.

Perform Attrition Determines when a unit is being attacked and modifies its

health based on the current attrition rate.

Put on MOPP Gear If a simulation object has MOPP gear, when it enters a

hazardous area, it stops and changes to MOPP level 4.

Receive Construction Allows an engineering object to receive construction from

other simulation objects.

Resize Footprints Updates the size of a simulation object’s physical and

sensor footprints.

Update Combat Effective- ness

Updates the combat effectiveness state of a simulation object.

Update EW Degradation Processes jamming interactions and computes the level

of degradation in communications and radar from these attacks.

Use Supplies Uses supplies based on the simulation object’s current

activities.

image


image 32. Creating Scripted Tasks and Sets


VR-Forces lets you create new tasks and set data requests by writing scripts. You do not need to know C++ or have a developers license to write these scripts. This chapter explains how to create and edit script meta data and how to organize and enable scripts. Chapter 33, Writing Scripts explains how to write script code.

Introduction to Scripts 32-3

Scripted Tasks 32-4

Scripted Sets 32-5

Reactive Task Scripts 32-5

Background Process Scripts 32-5

Script Metadata 32-5

The Lua Scripting Language 32-5

Creating a New Script 32-6

Specifying the Script ID 32-11

Specifying a Menu Icon 32-11

Specifying an Extended Name 32-12

Specifying a Short Description 32-12

Specifying Script Parameters 32-13

Specifying a Menu Location 32-17

Specifying Action Categories 32-18

Configuring a Script’s Availability to a Simulation Object Type 32-19

Specifying Equivalent Scripts for a Toolbar Button 32-23

Specifying the Programming Language for a Script 32-25

Creating Scripted Sets 32-26

Creating Reactive Tasks 32-27

Creating Background Processes 32-29

Saving Scripts 32-30

image

Creating Scripted Tasks and Sets

Editing a Script 32-30

Filtering the List of Scripts 32-31

Organizing Scripts into Folders 32-31

Adding a Folder 32-31

Renaming a Folder 32-31

Deleting a Folder 32-32

Adding Scripts to a Folder 32-32

Removing a Script from a Folder 32-32

Exporting and Importing Scripts 32-32

Importing a Script Package 32-33

Copying a Script 32-34

Deleting a Script 32-34

Creating a System Script 32-35

Including System Scripts on the Task and Set Menus 32-35

Specifying a Script Editor 32-37

Editing Lua Files 32-38

    1. Introduction to Scripts

      The script capability in VR-Forces allows you to create new tasks and set data requests for simulation objects without using the VR-Forces Toolkit and C++ API. Scripts use the Lua programming language. The actions that simulation objects can carry out are still limited to the basic C++ tasks provided by VR-Forces. However, since Lua is a full- featured scripting language, it is far more powerful than the language used to create plans and you can be much more creative in how you use the basic tasks. In addition to functions for tasks and sets, Lua scripts can make many types of calls to the simulation engine to get simulation object status or other simulation data. Scripts can also set some simulation data.

      Scripts are classified as system scripts or as scenario scripts. System scripts are saved as part of the SMS and are available to all scenarios that use that SMS. Scenario scripts are available only in the scenario for which the script was created. However, you can save a scenario script as a system script if you want to and, just as with other data used by VR- Forces, there are ways of copying scripts from one VR-Forces installation to another.

      VR-Forces supports the following types of scripts:

      • Task. Scripted tasks can be listed on the Task menu and used as independent tasks or in plans just like C++ tasks.

      • Reactive task. A reactive task monitors the simulation and gets activated when the conditions set in the script become true. Reactive tasks are enabled or disabled for simulation objects through the GUI.

      • Background process. A background process runs continuously from the time a simulation object is created. There is no user interface for assigning background processes to simulation objects. Their use is based entirely on the scripting process.

      • Set data request. Set data request scripts change simulation object state without interrupting the current task.

Although creation of scripts requires that you have some programming skills, you do not need to know C++, use a compiler, or use the VR-Forces APIs to write these scripts.

Creating Scripted Tasks and Sets — Introduction to Scripts

image


From a Lua script you can:

VR-Forces includes a text editor (SciTE) to use as the default script editor. You can configure VR-Forces to use a different editor if you want to. For details, please see “Specifying a Script Editor,” on page 32-37.


      1. Scripted Tasks

        Scripted tasks can be added to the Task menu and are treated just like the tasks that are built into VR-Forces.

        When you create a scripted task, you can specify input parameters. When you assign the task to a simulation object, either from the Task menu or in a plan, VR-Forces builds a dialog box for the task that includes all of the parameters specified for the script.


      2. Scripted Sets

        Scripted sets can be added to the Set menu and are treated just like the set data requests that are built into VR-Forces.

        When you create a scripted set, you can specify input parameters. When you assign the set to a simulation object, either from the Set menu or in a plan, VR-Forces builds a dialog box for the set that includes all of the parameters specified for the script.

        A scripted set cannot issue tasks to the entity that executes it or to any other entity.


      3. Reactive Task Scripts

        Reactive tasks monitor a simulation and get activated when the conditions set in the script become true. Reactive tasks are not added to the Task menu. In most respects the process for creating and writing reactive tasks is the same as creating and writing all scripts. Assume that all details about scripts apply to reactive tasks unless noted other- wise. For conceptual details about reactive tasks, please see “Reactive Tasks,” on

        page 26-12.


      4. Background Process Scripts

        The background process is a script that runs in the background for the simulation object types for which it was written. Since a background process has no user interface, it does not have any input parameters. When you create a background process, you specify the simulation object types for which it is available and you write the script.


      5. Script Metadata

        A script has two major components, the script code, and the script metadata. The meta- data provides all of the information that VR-Forces needs to store the script, add it to a menu, and generate a dialog box.


      6. The Lua Scripting Language

Lua is a lightweight scripting language used by VR-Forces to implement the script feature. VR-Forces includes a set of Lua functions that map the built-in tasks and set data requests as well as the ability to obtain simulation object state information. You use these functions as the starting point for building new tasks. For details about the Lua language, please see the Lua web site (www.Lua.org).


    1. Creating a New Script

      To create a new script, you specify the metadata for the script and write the script code. A script’s metadata specifies the script’s name, where it will be placed on a menu, and its parameters, if any. Specifying metadata may be an iterative process, particularly the parameters, which may change as you write the code for the script. However, the minimum first step in creating a script is to specify a name for the script and add it to the list of scripts. Once you do this, you can edit the metadata and the code as needed until you have completed the script to your satisfaction.

      All new scripts are created as scenario scripts. If you want to create a new system script, you save the scenario script as a system script. For details, please see “Creating a System Script,” on page 32-35.


      image

      i

      i

      To create a script, you must have a scenario open. This is true even if you plan to create a system script rather than a scenario script.


      image


      To create a new script:

      1. Open a scenario. (If you want to create a system script, you must create it in the context of a scenario. Then you will promote it to a system task.)

      2. Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).


        image

        Figure 32-1. Scripts dialog box


      3. If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)

      4. Choose Script New Script. The New Script dialog box opens (Figure 32-2).


        image


        Figure 32-2. New Scripted Task dialog box

      5. In the Script Type list, select the type of script you are creating (Task, Reactive Task, Set, or Background Process). The dialog box displays the correct set of meta- data for the type of script you chose.


      6. Complete the fields in the dialog box. They are described in Table 32-1 and in following sections.

        image

        Table 32-1: Script metadata


        Input Field Description

        Input Field Description

        Script ID A unique name for the script. VR-Forces generates a default name, but you will probably want to change it to something meaningful. It is your responsibility to make sure that it is unique. Please see “Specifying the Script ID,” on page 32-11 for details.

        Script Type One of the following:

      7. Optionally, click Preview to see the dialog box that the script will create.

      8. Optionally, click Edit Script to begin writing the code for this script.

      9. Click Add. The script is added to the list in the Scripts window.

      10. To save the script task as part of the scenario, save the scenario.

      11. Write the code for the script. For details, please see Chapter 33, Writing Scripts.


      1. Specifying the Script ID

        Each script must have a unique ID. VR-Forces generates a default ID, but it does not contain meaningful text. Therefore, you may want to change the ID.


        image

        !

        !

        The script ID is used internally by VR-Forces to manage how a script is executed. If a script is used in a plan, it is referenced by its script ID. If you change the ID, you must ensure that it is unique. You cannot edit the ID of a system script.


        image


        To specify the script ID:

        1. In the New Script (or Edit Script) dialog box, click the button to the right of the Script ID. The New Script ID dialog box opens.

        2. Type the ID you want to use.

        3. Click OK.


      2. Specifying a Menu Icon

        If you want to put an icon on the Task or Set menu next to the menu text, you can specify one. (Does not apply to reactive tasks and background tasks.)

        To specify a menu icon:

        image

        1. Click the Add button ( ) next to the Menu Icon label. The Select Menu Icon dialog box opens.

        2. Browse the directory structure and select the icon that you want to use.

        3. Click Open.

          image

          To remove a menu icon for a script, click the Remove button ( ) next to the Menu Icon label.


      3. Specifying an Extended Name

        Sometimes a script needs to be implemented differently for different types of simula- tion objects. To accomplish this you can write different scripts for each type of simula- tion object, but give the task the same name. The scripts are distinguished by their script IDs and VR-Forces picks the correct script using context sensitivity. For example, you might have two scripts with the IDs Move_To_Waypoint_Entity and Move_To_Waypoint_Unit. Both would have the name Move to Waypoint. When you wanted to give a Move to Waypoint task, you would select the simulation object and choose Move to Waypoint from the Task menu. VR-Forces would pick the correct version of the task.

        The one problem with this system is that in cases where VR-Forces does not enforce context-sensitivity of task or set lists, you would end up with two tasks called Move to Waypoint and no way to know which was the correct one to use for the simulation object that you wanted to assign the task to. The extended name solves this problem. If you specify an extended name for a script, it is used between scripts that use the same task or set name.


      4. Specifying a Short Description

        When you add a scripted task or set data request to a plan, the entry in the Plan window can be lengthy and cryptic. It often includes information, such as location values that are not easily understood or put to use by a reader. The Short Description field for a script lets you specify a short, meaningful description to be used in the Plan window.

        The description can include variable information. To include variable data, use the syntax $variable_name, where variable_name is one of the variables for the script. For example, the default listing for the Move to Waypoint (Plan Along Roads) task is:

        move-to-waypoint-path-plan: destination=Waypoint1

        If you specify a short description of Move to $destination (Plan Path), the listing in the Plan window would be:

        Move to Waypoint1 (Plan Path)


      5. Specifying Script Parameters

        Scripted tasks and sets can take input parameters. When you specify parameters for a script, VR-Forces automatically builds a dialog box that lets you enter the parameter values. The parameter types that you can specify for a script are as follows:

        • Aggregate Formation. Provides a list of formations for units.

        • Altitude MSL. Altitude above mean sea level.

        • Altitude Rate Change. Lets you specify the rate at which an aircraft changes alti- tude.

        • Animated Movement. Lets you assign an animated movement to an entity.

        • Bomb Resource. Creates a list of bomb resources.

        • Boolean. Creates a check box.

        • Choice (List). Specifies choices presented in a drop-down list.

        • Choice (Option Button). Specifies choices presented as option (radio) buttons.

        • DI-Guy Animation. Lets you select a DI-Guy animation.

        • DI-Guy Appearance. Lets you select a DI-Guy appearance.

        • Date/Time. Specifies the date and time.

        • Depth MSL. Specifies the depth below mean sea level.

        • Direct Fire Weapon.

        • Distance. Specifies a distance.

        • Embedded Entity. Lets you select an embedded entity to deploy.

        • Emitter. Entity emitter ID.

        • Entity Type. Lets you specify one object type enumeration.

        • Entity Types. Lets you specify a list of object type enumerations.

        • Force. Specifies the force.

        • Heading. Heading, in degrees.

        • Indirect Fire Weapon. Specifies an indirect fire weapon.

        • Integer. A whole number.

        • Location (with altitude). Vector description of a location, in geocentric, including altitude.

        • Location (without altitude). Vector description of a location, in geocentric, altitude not included.

        • Munition Resource. Creates a list of munitions.

        • Naval Mine Resource. Specifies a naval mine resource.

        • New Tactical Graphic. Lets you define a tactical graphic.

        • Observer Mode. Specifies an observer mode, for example, Stealth, IG, or XR.

        • Observer Saved View. Specifies a saved view.

        • Offset Location. Specifies an offset to the side, behind, and above, as in the Follow Entity task.


        • Real. A floating point decimal number.

        • Resource. Creates a list of available resources.

        • Separator. Lets you put a separator in the generated dialog box. This is just for formatting purposes.

        • Simulation Object (Single). Lets you select one simulation object in a list window.

        • Simulation Objects (Multiple). Lets you select multiple simulation objects in a list window.

        • Speed. Any kind of rate, such as speed, climb rate, and so on.

        • String. An alphanumeric string.

        • Time. Time in days:hours:minutes:seconds.

        • Topographic Orientation. Specifies orientation in topographic coordinates.

        • Turn Rate. Turn rate in radians/second.

        • Weapon. Specifies a weapon.

        If a script does not have any input parameters, it executes as soon as it is assigned to a simulation object, like the Wait command does.

        To specify a parameter for a script:

        image

        1. Click the Add button ( ) above the Parameters list. The Add Parameter dialog box opens (Figure 32-3).


          image

          Figure 32-3. Add Parameter dialog box

        2. Select the type of parameter from the Type list. If appropriate, the dialog box redis- plays to request the details required for the variable type you selected.


        3. Fill out the fields as follows:

          All of the parameters have the following fields:

          • Parameter Name. The name to be used by the Lua script for this parameter. For example, if you give a parameter the name taskDestination, in the Lua code for the script, the parameter will be accessed as taskParameters.taskDestination.

          • Label. This is the text used on the dialog box that is generated for the task. If you leave this field blank, the parameter name is used.

          • Tool Tip. Optional text for a tool tip.

          • Indent Level. The number of pixels to indent the parameter on the task dialog box. This allows you to apply some formatting to the dialog box.

          • Visible check box. Specifies that the parameter be included on the script dialog box. (You might want a parameter to be available in the code, but not have it set by a user when the script is assigned.)

            Many parameters let you specify a default value or state.

            Some parameters let you specify a range for the acceptable values:

          • Range Bottom. The lowest acceptable value for this parameter.

          • Range Top. The highest acceptable value for this parameter.

            The Boolean parameter type lets you create a check box. You can specify that the default be checked or unchecked.

            For details about adding choices to a Choice parameter, please see “Specifying Choices for the Choice Parameters,” on page 32-15. For details about adding cate- gories to a filtered list, please see “Specifying Categories for a Simulation Object,” on page 32-16.


            Specifying Choices for the Choice Parameters

            The Choice parameters require a list of choices, which get added to the dialog box as option buttons or as a list. You can add choices, edit them, and delete them.

            To add a choice:

            image

            1. Click the Add Parameter button ( ) on the Choice Box Values line. The New Choice dialog box opens.

            2. Type the text for the choice.

            3. Click OK.

            4. Repeat this procedure for each choice that you want to have available. (The last choice added becomes the default choice.)


            Specifying Categories for a Simulation Object

            The Simulation Object parameter lets you build a list of categories on which to filter the display of simulation object types in a dialog box.

            To add a category to the simulation object list:

            image

            1. Click the Add Parameter button ( ) on the Filters line. The Choose Filter dialog box opens.

            2. Select a filter from the Filters list.

            3. Click OK.

            4. Repeat the procedure to add as many filters as you want.


            Editing the Category List for a Simulation Object Parameter

            You can edit the list of filter categories for a Simulation Object parameter. The edit operation is essentially a replacement of the current category with a new one. You can achieve the same effect by deleting the current category and adding a new one.

            To edit the list of filter categories in a Simulation Object parameter:

            1. Select the parameter you want to edit in the Parameters list on the New Scripted Task dialog box.

            2. Click the Edit button image). The Script Variable dialog box opens.

            3. In the Filters list, select the filter that you want to edit.

            4. Click the Edit button image). The Choose Filter dialog box opens.

            5. Select the filter category that you want to use.

            6. Click OK. The original category is removed and the new one is added.

            To delete a category from a Simulation Object parameter:

            1. Select the parameter you want to edit in the Parameters list on the New Scripted Task dialog box.

            2. Click the Edit button image). The Script Variable dialog box opens.

            3. In the Filters list, select the filter that you want to delete.

              image

            4. Click the Delete button ( ). The category is removed from the list.


      6. Specifying a Menu Location

        Scripted tasks get added to the Task menu unless you specify that they not be shown (by clearing the Show Task on Task Menu check box). Scripted set data requests get added to the Set menu. The default location is the top level of the menu. However, you will probably want to organize your tasks and sets using the submenus provided by VR- Forces or in newly created submenus. The New Script dialog box displays the menu under which the script is placed. It does not show the full path from the top level menu.

        You can also add a scripted task or set to the top level right-click menu. The script can be listed in both places.


        image

        i

        i

        When you add a script to a menu, it does not appear on the menu until you reload the scenario.


        image


        To specify a menu location for a script:

        1. On the Menu Location line, click the Edit button image). For task scripts, the Select Location on Task Menu dialog box opens (Figure 32-1). For set scripts, the Select Location on Set Menu dialog box opens. The two dialog boxes are functionally identical.


          image

          Figure 32-4. Select Location on Task Menu dialog box

        2. To add the script to an existing submenu:

          1. Expand the submenu on which you want to put the script.

          2. Select the menu item that you want the new script to be next to.

          3. To put the new script above the selected menu item, select the Add Before Selected option. To put the new script below the selected menu item, select the Add After Selected option.

          4. Click OK.


        3. To create a new submenu for the script:

          1. Select the submenu next to where you want to add the new submenu.

          2. To add the new menu before the selected submenu, click Add Menu Before. To add the new menu after the selected submenu, click Add Menu After. The New Menu Name dialog box opens.

          3. Type a name for the new submenu.

          4. Click OK.

          5. Add the script to the new submenu using the procedure in step 2.


      7. Specifying Action Categories

        Some VR-Forces tasks can run at the same time as other tasks, while some are mutually exclusive. This is called task concurrency. (For details about concurrent tasks, please see “Concurrent Task Execution,” on page 26-5.) The C++ tasks provided with VR-Forces are organized in groups to help manage concurrency. They are configured in

        ./data/simulationModelSets/<model_set>/vrfSim/taskRules/default-task-rules.tsk.

        In the New Script dialog box, these groups are represented as action categories. The action categories displayed in the New Script dialog box are configured in ./data/simula- tionModelSets/<model_set>/vrfSim/taskRules/actionCategories.tsk. (For details about configuring action categories, please see “Configuring Action Categories,” on

        page 26-36.)

        When you create or edit a scripted task you can specify which groups of tasks the new task can run concurrently with and which it will interrupt. By default, the Movement category is selected, which means that if you do not change the setting, the new task will interrupt movement tasks.

        To specify which tasks a scripted task will interrupt, in the Action Categories list, select the categories to interrupt. For example, if the new task involves movement, you probably want it to interrupt other movement tasks, so you would select the Movement category check box. If it is a new type of message task, you probably want to let it run concurrently with movement tasks, so you would clear the Move- ment category check box.


      8. Configuring a Script’s Availability to a Simulation Object Type

        Scripts can be available to a simulation object based on the following criteria:

        The default setting for new scripts is that they are available to all simulation objects.

        Availability by simulation object type and by Behavior Set is configured in the New Script and Edit Script dialog boxes. Table 32-2 shows the interaction of these settings.

        Table 32-2: Scripted task availability


        Available by Entity Type

        Available by Behavior Set

        Availability

        Available by Entity Type

        Available by Behavior Set

        Availability

        image

        The script is available only to those simulation object types listed.

        image image The script is available to all simulation objects, but only if one of the selected behavior sets is applied to the simulation object’s force.

        image image The script is available to the specified simulation object types, but only if one of the selected behavior sets is applied to the simulation object’s force.

        image


        Specifying the Valid Simulation Object Types for a Script

        You can restrict a script to specific simulation object types. If you do this, the script will not appear on the Task or Set menu when you select a simulation object for which it is not valid. Just as with built-in VR-Forces tasks and sets, there are cases, such as for global plans, where VR-Forces cannot determine the simulation object context and the script will be available on the menu even though it is not appropriate to the simulation object that you selected. In those cases it is up to you to know that a task or set is valid.

        To specify the valid entity types for a script:

        1. Select the Make Available Based on Entity Type check box.

          image

        2. Click the Add button ( ) on the Valid for Entity Types line. The Entity Type dialog box opens (Figure 32-5). You can build an enumeration by selecting options from the enumeration field lists or you can type in the enumeration directly.


          image

          Figure 32-5. Entity Type dialog box

        3. For each field of the simulation object type (Kind, Domain, Country, and so on), select an option from the list.

          The options are drawn from the SISO Enumerations document. As you select an option, the enumeration at the bottom of the dialog box changes to reflect your choice. You do not have to make a selection for each field. VR-Forces uses wild carding to match simulation objects against the final enumeration.

        4. If appropriate, add additional enumerations for each simulation object type that is valid for the script.


          Specifying Availability by Behavior Set

          You can restrict a script to specific Behavior Sets. If you do this, the task will not appear on a menu when you select a simulation object whose force does not have the Behavior Set assigned to it.

          To specify that a script is available by Behavior Set:

          1. Select the Make Available Based on Behavior Set check box.

          2. Select each Behavior Set for which you want this script to be available.


          image

          i

          i

          You must create the Behavior Sets before you can assign scripts to them. All available Behavior Sets are automatically listed in the dialog box window.


          image


          Specifying a Scripted Task or Set in a System Definition

          Some scripted tasks and sets are available to simulation objects because they are speci- fied in a system that the simulation object uses. They are not assigned to simulation object types as part of the script meta data.


          image

          i

          i

          This method is used for many of the system scripted tasks supplied with VR- Forces.


          image


          Scripted tasks and sets are specified in a system definition by their script IDs in the script-ids parameter. (In AggregateLevel.sms, some scripted tasks for combat engineering objects are specified in the create-script-id, improve-script-id, and destroy-script-id parame- ters.) Script IDs can be specified in a script-enable-controller and in controllers derived from it.


          The following example is from ground-aggregate-movement.sysdef in AggregateLevel.sms. Any simulation object with this system definition can use the Maximum_Speed_Modi- fier, Halt_Movement, Move_To_Location_Plan_Path, and Move_To_Way- point_Plan_Path scripted tasks. The variables described in the script-variables block are accessible to the script through the vrf:getScriptAttribute() function.

          (script-enable-controller

          (component-descriptor-type "script-enable-controller-descriptor")

          ...

          (script-ids "Maximum_Speed_Modifier" "Halt_Movement" "Move_To_Location_Plan_Path" "Move_To_Waypoint_Plan_Path")

          (script-variables

          (maximum-speed-modifier-variables (script-id "Maximum_Speed_Modifier") (variables

          (DtRwReal Rain-Modifier-By-Intensity

          $rain-modifier-by-intensity) (DtRwReal Snow-Modifier-By-Intensity

          $snow-modifier-by-intensity) (DtRwReal Visibility-Degrades-When-Below

          $visibility-degrades-when-below) (DtRwReal Visibility-Can-Degrade-Speed-Up-To

          $visibility-can-degrade-speed-up-to)

          )

          )

          (move-to-location-variables

          (script-id "Move_To_Location_Plan_Path") (variables

          (DtRwString Obstacle-Feature-Query "MAK_OBSTACLE") (DtRwString Path-Feature-Query "MAK_ROAD")

          )

          )

          ...

          )

          )

          The following example is from the aggregate-5-inch-gun.sysdef in AggregateLevel.sms. It adds the script-ids parameter to the unit-indirect-fire-controller, which is derived from the script-enable-controller. Any simulation object with this system can use the Indirect Fire and Limited Munition Attack scripted tasks.

          (weapon-indirect-fire (systems ) (sensors ) (controllers

          (aggregate-indirect-fire-controller

          (component-descriptor-type "aggregate-indirect-fire-controller- descriptor")

          (component-type "aggregate-indirect-fire-controller") (min-tick-period -1.000000)

          (min-tick-period-variance -1.000000)

          (process-state-repository-name "aggregate-indirect-fire- controller-process-state-repository-default")

          (process-state-repository-type "aggregate-indirect-fire- controller-process-state-repository")

          (is-enabled True)

          (script-ids "Indirect_Fire" "Limited_Munition_Attack") (weapon-name "5 inch shell")

          ...


          )

          )

          The following example is from obstacle-builder.sysdef and shows the create-script-id and

          improve-script-id parameters:

          (creatable-objects (affectable-object

          (object-type 1 (16 1 0 62 3 0 0))

          (time-to-complete $time-to-create-abatis) (range $creation-range-abatis)

          (create-script-id "Construct_Abatis") (improve-script-id "Improve_Obstacle")

          )

          ...

          )


      9. Specifying Equivalent Scripts for a Toolbar Button

        There may be occasions when you want to have tasks or sets with the same name that work differently depending on the simulation object you give them to. For example you might have a movement task that works one way for an individual entity and another way for a unit. You can ensure that when you select a simulation object it gets the correct version of the script by specifying the simulation object type that the script is available to. To simplify the Task or Set toolbars, you can map these different scripts to the same toolbar button. This is done by specifying that one script is equivalent to another script.

        If you map multiple scripts to the same toolbar button, when you select a simulation object, the toolbar button is enabled and you can give the simulation object the task or set. VR-Forces chooses the correct version of the script. If you select multiple simula- tion objects that would have different versions of the script, the toolbar button becomes disabled.


        To specify an equivalent script for a Task or Set Toolbar button:

        1. Create a new script.

        2. On the New Script dialog box (or Edit Script dialog box), select Show Task on Task Toolbar (or Show Set on Set Toolbar).

        3. Click the Toolbar Location edit button image). The Select Location on Task (Set) Toolbar dialog box opens.

        4. Select the task or set that you want this script to be equivalent to. The Equivalent To button becomes active.

        5. Click the Equivalent To button. Text is added to the script’s entry in the list indi- cating the script it is equivalent to (Figure 32-6).


          image


          Figure 32-6. Select Location on Task Toolbar dialog box


          image

          i

          i

          Do not move the new script to a different location on the toolbar. Moving it breaks the equivalency. Users will click the equivalent task or set’s button to access this it


          image


        6. Click OK.

        7. Save the script.


      10. Specifying the Programming Language for a Script

        The Language list in the New Script dialog box has two options, Lua and C++. In most cases you will choose Lua and write a script to implement the task or set. However, since the script interface automatically generates dialog boxes and updates menus, it can be a convenient way to add the GUI component for new tasks or sets that developers have written in C++ with the VR-Forces Toolkit. Developers who take this approach do not have to rebuild the VR-Forces front-end or write a plug-in to add their new task or set to the menu and code a dialog box.


        image

        i

        i

        The Language option only applies to Task and Set type scripted tasks. Reactive tasks and background processes are always written in Lua.


        image


        If a developer adds a new C++ task controller using this approach, it looks for the script ID of the scripted task. For example, the Deploy and Recover tasks for embedded enti- ties use the scripted task interface to create their dialog boxes. The addTask example in the VR-Forces Toolkit demonstrates this method of adding tasks. For more informa- tion, please see VR-Forces Developers Guide.

        You can display C++ tasks and sets in the Scripts dialog box by selecting the Show C++ Tasks check box (Figure 32-7).


        image


        Figure 32-7. C++ tasks


      11. Creating Scripted Sets

        The meta data for a scripted set is identical to that of a scripted task except that a scripted set does not have action categories.

        To create a scripted set:

        1. Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).

        2. If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)

        3. Choose Script New Script. The New Script dialog box opens (Figure 32-2).

        4. In the Script Type list, select Set. The New Script dialog box redisplays to show the metadata fields for a scripted set (Figure 32-9).


          image

          Figure 32-8. New Script dialog box, scripted set

        5. Complete the fields in the dialog box. Fields that are common to all scripts are described in Table 32-1.


      12. Creating Reactive Tasks

        The process for creating a reactive task is largely the same as for creating other scripts. This procedure focuses on the differences.

        To create a reactive task:

        1. Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).

        2. If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)

        3. Choose Script New Script. The New Script dialog box opens (Figure 32-2).

        4. In the Script Type list, select Reactive Task. The New Script dialog box redisplays to show the metadata fields for a reactive task (Figure 32-9).


          image

          Figure 32-9. New Script dialog box, reactive task

        5. Complete the fields in the dialog box. Fields that are common to all scripts are described in Table 32-1.

        6. To make this reactive task enabled by default, select the Enabled By Default check box.


        7. In the Default Priority box, type the priority for this task. The lower the number, the higher the priority. To help you set the priority, you can view a list of all reactive tasks that are valid for the simulation object types of this task so that you can consider their relative importance and set an appropriate priority.

        8. Optionally, click Compare Priorities to see a list of reactive tasks and their priori- ties.

        9. Click Add.


      13. Creating Background Processes

        The procedure for creating a background process is essentially the same as for other script types. The main difference is that there are fewer fields to complete in the New Script dialog box. For details about writing a background process script, please see “Background Processes,” on page 33-30.

        To create a background process:

        1. Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).

        2. If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)

        3. Choose Script New Script. The New Script dialog box opens (Figure 32-2).

        4. In the Script Type list, select Background Process. The New Script dialog box redis- plays to show the metadata fields for a background process (Figure 32-9).

        5. Complete the fields in the dialog box. Fields that are common to all scripts are described in Table 32-1.


          image

          Figure 32-10. New Script dialog box, background process

        6. Click Add.

Creating Scripted Tasks and Sets — Saving Scripts

image

    1. Saving Scripts

      When you create or edit a script, its listing in the Scripts window is in italics, prefaced by an asterisk. When you save the scenario, or promote a script to a system script, the script gets saved and the italics and asterisk get removed.

      It is likely that you will test scripts by running a scenario and you will want to edit the script as you find problems. If you create or edit a script while a scenario is running and you decide to rewind the scenario without saving it (which would be normal behavior for rewinding a scenario), you are prompted to preserve the changes to the script after the scenario rewinds. The script is still not saved and you will, therefore, receive the standard “scenario modified” prompt when you start the scenario again. You do not have to save the scenario if the only thing that changed is the script. You can continue to run the scenario and rewind while you are working on the script. Eventually you will have to save the scenario if you want to save your changes to the script.

      To save a scenario script, save the scenario.

      To save a system script, after updating the script in the Edit Script dialog box, click Update.


    2. Editing a Script

      You can edit scripts.


      image

      !

      !

      If you edit a system script, the changes affect all scenarios that use the script. You are responsible for ensuring that any changes have the intended results for all scenarios that are affected.


      image


      To edit the metadata for a scenario script:

      1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

      2. Select the script that you want to edit.


        image

        i

        i

        In the Script ID column the icon indicates the type of script, Task image), Reactive Task image), Set image), or Background Process image).


        image


      3. Choose Script Edit Script Meta Data, or double-click the script name. The Edit Script dialog box opens. (If you are editing a system script, you are prompted to confirm that you want to edit it.)

      4. Edit the metadata as desired.

      5. Click Update.

        Creating Scripted Tasks and Sets — Organizing Scripts into Folders

        image

    3. Filtering the List of Scripts

      You can filter the tasks listed in the Scripts dialog box by selecting options from the lists below the menu bar, as follows:

      • Script Access: Show system scripts, scenario scripts, or all scripts.

      • Script Type: Show scripted tasks, reactive tasks, sets, background processes, or all scripts.

      • Entity Type: Show scripts that apply to the selected simulation object type.


        image

        i

        i

        This filter is based on the Valid for Entity Types list for each script. Some scripts do not have any simulation object types listed. These scripts, such as Drop Naval Depth Charge, become available to simulation objects based on the systems that they have configured. Therefore, this list may be somewhat misleading in terms of the overall applicability of scripts to the different platforms.


        image


      • Show C++ Tasks: Toggles the display of tasks and sets that are written in C++, but whose GUIs are created using the script mechanism.


    4. Organizing Scripts into Folders

You can create folders and organize scripts by folder.


      1. Adding a Folder

        To add a folder:

        1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

        2. Choose Folders Add Folder. The Folder Name dialog box opens.

        3. Type a name for the folder.

        4. Click OK.


      2. Renaming a Folder

        To rename a folder:

        1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

        2. Select the folder that you want to rename.

        3. Choose Folders Rename Folder. The Folder Name dialog box opens.

        4. Type a new name for the folder.

        5. Click OK.

          Creating Scripted Tasks and Sets — Exporting and Importing Scripts

          image

      3. Deleting a Folder

        You cannot delete a folder that has scripts in it.

        To delete a folder:

        1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

        2. Select the folder that you want to delete.

        3. Choose Folders Delete Folder.


      4. Adding Scripts to a Folder

        To add a script to a folder, drag it onto the folder.


      5. Removing a Script from a Folder

To remove a script from a folder, drag it away from the folder.


    1. Exporting and Importing Scripts

      Scenario scripts are saved in a scenario’s SPT file, not as individual scripts. If you want to make a scenario script available to other scenarios, but you do not want to save it as a system script, you can export the script from the scenario in which you created it and import it into any other scenario. You can export multiple scripts to one file as a script “package”.


      image

      i

      i

      You cannot add or remove scripts from a script package. To change the contents you would have to create a new package.


      image


      If scripts are organized in folders, when you save them the folder structure is also saved.

      To export scripts:

      1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

      2. Select the scripts that you want to export. (The window supports typical methods for selecting multiple entries in a list.)

      3. Choose Script Export Script Package. The Choose Script File dialog box opens. By default it opens in ./userData/taskScripts.

      4. Type a name for the scripts file.

      5. Click Save. The scripts gets saved to a file with the extension .spt. The file contains the metadata and the script code.

        Creating Scripted Tasks and Sets — Exporting and Importing Scripts

        image

            1. Importing a Script Package

              If you import a script package that has multiple scripts, you can choose which scripts to import. Scripts get imported with the folder hierarchy that they were saved in.

              To import scenario scripts:

              1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

              2. Choose Script Import Script Package or click Import Scripts. The Choose Script File dialog box opens.

              3. Select the script file that you want to import.

              4. Click Open. The Import dialog box opens (Figure 32-11). It lists the scripts saved in the script file.



                image

                Figure 32-11. Import dialog box

              5. Select the scripts that you want to import.

              6. Click Import.

        Creating Scripted Tasks and Sets — Copying a Script

        image

    2. Copying a Script

      If you want to create a new script that is similar to an existing one, you can copy an existing script and then edit it for its new purpose.

      To copy a script:

      1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

      2. Select the script that you want to copy.

      3. Choose Script Duplicate. The New Script dialog box opens. If you copied a scenario script, the duplicate script is assigned a new script ID. If you copied a system script, the script ID is not changed. You will have to change the script ID manually.


        image

        i

        i

        If you do not change the script ID for a copied system script, the system script gets removed from the list of scripts for this scenario and the new script is added as a scenario script. This lets you experiment with changes to a system script without actually changing it. The original system script will still be available to other scenarios.


        image


      4. Edit the script.

      5. Click Duplicate. The script is added to the list.


    3. Deleting a Script

      If you delete a script that is assigned to a simulation object in a scenario, a task assign- ment, whether as an independent task or as part of a plan, will fail. If a scripted task is used as a subtask in another scripted task, that scripted task will fail. Scripted sets also fail. VR-Forces does not warn you if either of these cases exist. It is your responsibility to consider the effects of deleting a script.

      To delete a script:

      1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

      2. Select the script that you want to delete.

      3. Choose Script Delete Script.

        Creating Scripted Tasks and Sets — Creating a System Script

        image

    4. Creating a System Script

      To create a system script, you create a scenario script and then save it as a system script. System scripts are saved in ./data/simulationModelSets/<model_set>/scripts. A system script has two files. The metadata is saved in a file ending with the extension .xml. The code is saved in a file with the extension .lua.

      To save a scenario script as a system script:

      1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

      2. Select the script that you want to save as a system script.

      3. Choose Script Promote to System Script. You are prompted to confirm the change.

      4. Click Yes.


      1. Including System Scripts on the Task and Set Menus

        Most of the system scripted tasks and sets included with VR-Forces are listed on the Task and Set menus. The scripts in the Examples folder and a few others are not listed. You can specify whether or not particular scripted tasks or sets are listed. You might want to do this to reduce clutter on the menus. Or you might want to limit the tasks available to players in a particular deployment of VR-Forces.

        A system script’s inclusion on a menu is controlled by the following settings:

Creating Scripted Tasks and Sets — Creating a System Script

image


image

Figure 32-12. Show script on menu check box

Table 32-3 shows when a scripted task is listed on a menu based on the configuration check boxes selected.

Table 32-3: System scripted task inclusion on Task menu


image

Show Script on Menu check box


image


image


image


image

System script list check box


image


image


image


image

Task included on menu


Yes No

image

Yes, for this scenario. No


To specify the availability of a system script on a menu:

  1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

  2. In the list of system scripts, select the script whose availability you want to change. Use Table 32-3 to determine which check box configuration you need for your desired menu status.

  3. Choose Script Edit Script Meta Data. The System Script Editing prompt opens. (If you have disabled this prompt, the Edit Script dialog box opens. Skip to step 5.)

  4. In the System Script Editing prompt, click Yes. The Edit Script dialog box opens.

  5. Select or clear the Show Task on Task Menu check box (or the equivalent for sets).

  6. Click Update.

    Creating Scripted Tasks and Sets — Specifying a Script Editor

    image


  7. In the list of scripts, select the check box next to the system script you are editing to make it available. Clear the check box to make it unavailable.


    1. Specifying a Script Editor

      VR-Forces installs SciTE as the default script editor for scripted tasks. However, you can use any text editor that you want.

      To specify the editor to use for scripts:

      1. Choose Settings Application. The Application Settings dialog box opens.

      2. Select the Script Options page (Figure 32-13).


        image

        Figure 32-13. Script Options page

      3. Click the Browse button image) next to the Script Editor box. The Choose Script Editor dialog box opens.

      4. Select the application that you want to use as the editor.

      5. Click Open.

        Creating Scripted Tasks and Sets — Editing Lua Files

        image

    2. Editing Lua Files

      To edit the code for scenario scripts you need to work through the Script GUI because the scripts are embedded in the scenario scripts file rather than being saved as individual Lua files. System scripts are saved as Lua files, but even in this case it is better to edit them in the context of the entire script process rather than by editing the Lua file.

      However, VR-Forces includes some libraries of Lua functions that are independent of any of the scripts. They are available to be included in your scripts. If you want to edit the functions in these libraries or add to them, you need to edit the individual Lua files. The function libraries are in ./userData/scripts. You can open them in any editor, or access them through the Scripts dialog box.

      To edit a Lua file from the Scripts window:

      1. Choose Simulation Scripts. The Scripts window opens (Figure 32-1).

      2. Choose Script Edit External Script. A file chooser dialog box opens.

      3. Select the script that you want to edit. The file opens in a text editor.

      4. Edit the file.

      5. Save the file.


image

33. Writing Scripts


This chapter explains how to write Lua scripts for scripted tasks and sets.

The VR-Forces Lua Interface 33-3

Lua Classes 33-3

Lua Modules 33-6

Script Loading and Execution 33-6

Script Entry Points 33-7

The Script Execution Sequence 33-9

Limitations for Checkpointing Scripts 33-12

Editing Scripts While a Scenario is Running 33-14

Tasks and Subtasks 33-15

Monitoring the Status of Tasks and Subtasks 33-16

Stopping Tasks 33-16

Task Parameters 33-16

Geometry 33-18

Location3D 33-18

Vector3D 33-18

VectorOffset3D 33-20

VectorGeoc3D 33-20

Coding Messages for Translation 33-21

Error Detection 33-21

Interactive Scripts 33-23

A Basic Scripted Task 33-23

Create and Move to Waypoint Metadata 33-24

The Create and Move to Waypoint Lua Script 33-26

A Simple Scripted Set 33-28

image

Writing Scripts

A Simple Reactive Task 33-29

Background Processes 33-30

    1. The VR-Forces Lua Interface

      The VR-Forces Lua interface provides predefined elements that you can use to create scripts. These elements include object classes that represent the simulation, simulation objects, and geometric objects, plus Lua modules that provide tools for common tasks.

      The classes and functions in the Lua interface are documented in the VR-Forces Lua API Documentation. This is a set of HTML files similar to the VR-Forces Toolkit documentation. It is accessible from the Windows Start menu or in

      ./doc/luadoc/index.html.


      1. Lua Classes

        The Lua interface defines classes for common objects and functions. The classes in the interface are not fully featured classes as in the C++ language, but they do abstract the representation of information associated with an object and collect a set of methods related to the object. In Lua, to call a method fn on object obj, write:

        obj:fn()

        Several of the classes defined in the interface do not have constructors, because their objects are pre-defined or created only as return values to other functions. The classes and pre-defined objects in the interface are as follows:

        • ComponentSystem. A component system is a capability that is assigned to a simula- tion object in the Simulation Object Editor. Systems represent movement and damage capabilities, and represent individual weapons and sensors. In scripts, system objects are obtained from the ownship simulation object (“this”) with a call to getSystem(), passing the name of the system (as used in the Entity Editor) as an argument. The script can then access various attributes of the system through getAttribute calls.

        • FeatureSet. This class represents a set of features obtained from a query to the terrain database. A FeatureSet is created with a vrf query function. FeatureSet methods allow a script to examine the features to determine their attribute values, vertex locations, and so on.

        • Location3D, Vector3D, VectorGeoc3D, VectorOffset3D. These classes represent geometric objects. For more information, please see “Geometry,” on page 33-18.

        • ScriptAnimationModel. ScriptAnimationModel refers to an animation model that can be used by a scripted task to animate an entity's movement. This class is serial- ized to the simulation and might contain movement data if supplied by the devel- oper.

        • SensorGimbal. SensorGimbal is a class of Lua object that represents a sensor that rotates on a gimbal.

        • SimObject. SimObject refers to a single object in the simulation. It may be an entity, waypoint, route, or any other simulation object. These objects may be VR-Forces simulated objects, or remote objects received over DIS or HLA by VR-Forces.

        • SwingingArtPart. SwingingArtPart is a class of Lua object that represents a rotating

          Writing Scripts — The VR-Forces Lua Interface

          image


          articulated part.

          • TranslatableArtPart. TranslatableArtPart is a class of Lua object that represents a translating articulated part.

          • TranslatableStream. TranslatableStream is a text stream class that can be translated by VR-Forces for display in the GUI as text that is translated to the current language the user is displaying (as long as those translations exist.)

          • SimObject. SimObject is a class that represents simulation objects in VR-Forces. There is no constructor for SimObjects in the interface, but there are vrf functions that create objects, that get objects by name, that get nearby objects, and so on. SimObject methods are provided for getting information about the object such as location, force type, and embarkation status.

          • this. this is an object of class SimObject that is defined for all Lua scripts. It represents the simulation object running the script, also known as “ownship”. It is not possible to construct a this object in a script. In addition to being able to use all of the SimObject methods, a Lua script can change the location and heading of this, manipulate its resources, and examine the contacts detected by the simulation object’s sensors.

          • vrf. vrf is defined as a global object for all Lua scripts. It is an instance of a class that represents the Lua interface; other instances cannot be created in a script. The vrf object provides functions that control and access information in the VR-Forces simulation.


          image

          i

          i

          In Lua, variables assigned to objects actually just hold a reference to an object, so that if one variable is assigned to another they will both hold a reference to the same object. In the following example, firstObj and secondObj refer to the same object.

          firstObj = getObjectByName("APC 1") secondObj = firstObj

          In most cases this is what a Lua programmer wants. However, for the geometric objects, a Lua programmer may sometimes want to make a copy of an object. A simple assignment does not make a copy in Lua, so the geometric objects have makeCopy() methods to provide copies.


          image


          Reserved Words

          Table 33-1 lists reserved words (in addition to those reserved by Lua), which should not be used except for their intended purpose.

          Table 33-1: Reserved words


          Name

          Module

          Function

          vrf

          vrf

          Module singleton

          this

          SimObject

          Ownship name

          ScriptVrfObject

          SimObject

          Class name

          Location3D

          Location3D

          Class name

          Vector3D

          Vector3D

          Class name

          VectorGeoc3D

          VectorGeoc3D

          Class name

          VectorOffset3D

          VectorOffset3D

          Class name

          ScriptFeatureSet

          FeatureSet

          Class name

          ScriptAnimationModel

          ScriptAnimationModel

          Global function

          vrfprint

          vrfutil

          Global function

          printDebug

          vrfutil

          Global function

          printVerbose

          vrfutil

          Global function

          printInfo

          vrfutil

          Global function

          printWarn

          vrfutil

          Global function

          printError

          vrfutil

          Global function

          EntityType

          vrfutil

          Global table of functions

          bhaveLoaded

          vrfutil

          Global function

          new

          fsm

          Function name


      2. Lua Modules

        The Lua interface includes Lua modules for use in Lua scripts. A module stuff can be accessed in a Lua script by writing

        require "stuff"

        The modules available in the interface are as follows:

        • vrfutil. Technically, vrfutil is not a Lua module. (It is not defined with a module function.) It is just a set of global utility functions. The Lua script template that opens when a new script is created contains:

          require "vrfutil"

          so that these functions are available to the script by default.

        • fsm. The fsm module defines a class that implements finite state machine logic. There is one function in this module, new(), which creates an fsm object.

        • exectool. The exectool module is a package of functions that supports the use of a single Lua function to describe the control flow of a scripted task. To use this tool, the task logic is described in a function we call a scriptFunction. This function is written as if it will execute up to a subtask invocation, and then wait until that subtask is completed before continuing.

The .lua module files are located in ./userData/scripts. You can add user-created modules to this directory and then import them into scripts with a require statement.


    1. Script Loading and Execution

      This section describes script entry point functions and the execution sequence for scripted tasks and sets. It also describes how VR-Forces checkpoints scripted tasks and executes them when a checkpointed scenario is run.


      1. Script Entry Points

        The Lua API includes functions that we call “entry points” to a scripted task. When you create a new script, they are included in the default script template. Unlike the Lua functions that you might write as part of a script, you do not have to call entry point functions from within the script. They are called by the simulation engine. (However, if an entry point function is not defined in a script, it does not get called.)

        • init(). Use init() to set up the initial state of your scripted task’s environment. The init() function is the first function called when a scripted task is executed. It is called when a task is assigned to a simulation object, even if the scenario is paused. It is never called again for the life of the scripted task.

        • tick(). The tick() function is the heart of every scripted task. It is called at every tick of the simulation engine once the simulation object has completed its initialization. Most of a scripted task's logic should be written into the tick() function as it is the only entry point function consistently called in the script.

        • suspend(). The suspend() function gets executed when a reactive task is triggered for a simulation object and the reactive task cannot run concurrently with the current task. The typical behavior, as embodied in the scripted task template, is to stop all tasks and subtasks.

        • resume(). The resume() function gets executed when a reactive task completes. The typical behavior is to reinitialize the suspended task.


          image

          i

          i

          As you can see from their descriptions, the suspend() and resume() functions do not exactly suspend and resume tasks as those terms are commonly understood. In most cases (this is task dependent), VR-Forces does not preserve the state of a simulation object’s tasks when they are suspended, it stops the tasks. Nor does it resume the previous task from the point at which it was suspended, it restarts the task from the current state of the simulation object. However, VR-Forces always saves the lua state of scripted tasks, so when a scripted task resumes, its variables may need to be reset in init() or checkInit().


          image


        • saveState(). If a script is running, the saveState() function is called just before a scenario is about to be saved. VR-Forces automatically saves the state of script execution. (For details, please see “Limitations for Checkpointing Scripts,” on page 33-12.) This function lets you do any additional processing to save the state of your scripted task. Most scripts do not use this function.

        • loadState(). If a script was running when a scenario was saved, the loadState() func- tion is called just after a scenario is loaded or rewound. VR-Forces automatically restores the state of a scripted task that was running when a scenario was saved. This function lets you do any additional processing required to restore the state of the script. If your script uses the saveState() function, you probably want to include complementary processing in loadState(). Most scripts do not use this function.


          image

          i

          i

          If your loadState() function assumes the presence of other simulation objects, you must take into account that other simulation objects might not have loaded yet when the function is called.


          image


          • shutdown(). The shutdown() function is called when the task is ending for any reason. You will not typically need to write any code in this function, however it is available if there is a case in which you want to do anything before the task ends.

          • receiveTextMessage(). The receiveTextMessage() function is called when the simu- lation object executing this task receives a text message. The function provides some data to determine what the text message is and which simulation object the text message came from. This function takes two arguments, the message and the sender. The message is a text string and the sender is the simObject that sent the message.

            The following script entry points are only used in reactive tasks:

          • check(). The check() function defines the condition under which the reactive task gets triggered. It keeps checking the condition until it becomes true, at which point it starts the reactive task.

          • checkInit(). The checkInit() function initializes the reactive task when it is enabled. It sets the initial conditions for the check() function. checkInit() runs when a reac- tive task is first enabled and runs again after the reactive task completes so that it can begin checking the condition again.


      2. The Script Execution Sequence

        A Lua script has several distinct sections, including the entry points described in “Script Entry Points,” on page 33-7 and the global commands in the script. When a scripted task is assigned to a simulation object, the following actions happen, even if the scenario is paused:

        1. The script environment is initialized. This step defines the vrf and this objects and all of the class functions in the Lua API.

        2. The script text is loaded. All Lua statements in the global scope are executed. Normally, the script defines (assigns initial values to) global variables here.

        3. The init() function is called.

          This sequence is followed whenever a scripted task is assigned, including the following situations:

          • A scripted task is assigned while the scenario is running.

          • A simulation object has a script assigned at the beginning of a scenario and the scenario is loaded or rewound.

          • You modify the script or script metadata while the script is running.

        If the simulation is running, after the init() function is called VR-Forces begins calling the tick() function at the period specified by the setTickPeriod() function (default: 0.5 seconds).

        Suppose a script “test” contains the following code:

        print("Global statements") t = {}

        function init() print("Init function") vrf:setTickPeriod(0.5) t[1] = 0

        end

        function tick()

        table.insert(t, vrf:getExerciseTime()) print("Tick ", #t)

        end

        If the script is assigned to a simulation object and then the scenario runs for a short time, the console output would be as follows:

        Global statements Init function

        DtCgfDispatcher::controlScenario: run Tick 2

        Tick 3

        Tick 4 DtCgfDispatcher::controlScenario: pause

        Figure 33-1 illustrates the control flow for a scripted task.



        Assign task

        Assign task


        Global scope

        Global scope


        init()

        init()


        tick()

        tick()



        image

        image

        image

        image

        image

        Is task

        complete? No


        image

        Yes


        shutdown()

        shutdown()

        Figure 33-1. Scripted task control flow


        The Script Execution Sequence for Reactive Tasks

        image

        Figure 33-2 illustrates the script execution sequence for reactive tasks. It is distinguished from that for scripted tasks by the addition of the checking process.


        Enable task

        Enable task


        Global scope

        Global scope


        checkInit()

        checkInit()


        check()

        check()



        image

        image

        image

        image

        image

        Is check

        true? No


        Yes


        init()

        init()

        Run task


        tick()

        tick()


        Is task

        complete? No


        Yes


        Figure 33-2. Reactive task control flow


        The Script Execution Sequence for Saved Scenarios

        When a scenario is saved (checkpointed), VR-Forces first runs saveState() and then saves the Lua state in the scenario file. (Checkpointing a scripted task has some limita- tions. For details, please see “Limitations for Checkpointing Scripts,” on page 33-12. For general details about checkpointing, please see “Saving a Scenario,” on page 7-27.) When a saved scenario is loaded, the following steps are taken to restore the scripted task:

        1. The script environment is initialized. This step defines the vrf and this objects and all of the class functions in the Lua API.

        2. The script text is loaded. All Lua statements in the global scope are executed. Global variables defined and initialized in this part of the script are re-initialized.

        3. VR-Forces restores the values of global variables to the saved values. These values replace the initial values assigned in step 2.

        4. The loadState() function is called.


        image

        i The init() function is not run when a scenario is reloaded.

        image

        Assume that the “test” scripted task described in the previous section is saved at the point shown in the sample code (t = 4). When the scenario is run from the checkpoint, the console output will be as follows:

        DtCgfDispatcher::controlScenario: run Tick 5

        Tick 6 DtCgfDispatcher::controlScenario: pause


      3. Limitations for Checkpointing Scripts

        When VR-Forces saves (or checkpoints) a scenario, it saves the following aspects of the Lua state in the checkpoint:

        • The values of global variables that contain strings, numbers, and objects (of the classes listed in “Lua Classes,” on page 33-3).

        • Tables, but only table values that contain strings, numbers, objects, and tables. Tables cannot contain values that refer to the same table, either directly or indi- rectly through another table.

          The following aspects of the Lua state do not get saved in a checkpoint:

        • Variables containing functions or threads.

        • Variables declared in the global scope with the keyword local preceding the declaration.

        • Table entries that do not use numbers or strings as keys.


          Lua scripts that contain elements that do not get saved can still be restored after a checkpoint if the global statements in the script reset the elements. For example, a vari- able containing a function is not saved in the scenario file, but if this variable is initial- ized in the global Lua statements, it is reset when those statements are loaded. However, if the value of this variable was changed during script execution (in the init() or tick() functions), then its value will not be restored correctly.

          Tables that reference themselves in the table do not get saved properly. To demonstrate how scripted tasks get saved, assume the following script:

          print("Global statements") a = 0

          t = {foo = 0, bar = 1}

          f = function () print("hello") end function init()

          print("Init function") vrf:setTickPeriod(0.5) a = 100 -- change a

          t.foo= 10 -- change t.foo t.bar = nil -- remove t.bar

          f = function () print("world") end -- change f end

          function tick()

          print ("Tick. a = ",a, "t.foo = ", t.foo, "t.bar = ", t.bar) f()

          print() end

          The output the first time the scripted task runs is as follows:

          Global statements Init function

          DtCgfDispatcher::controlScenario: run

          Tick. a = 100 t.foo = 10 t.bar = nil world

          When the scenario is saved and then reloaded, and the simulation is run again, the following is printed:

          DtCgfDispatcher::controlScenario: run

          Tick. a = 100 t.foo = 10 t.bar = 1 hello

          A comparison of the outputs reveals that variable a and table entry t.foo were restored to the correct values. However, table entry t.bar and function f were re- initialized in the global statements, but were not restored to the values they had when the scenario was saved.


          Saving the State of Global Variables

          Global variables get saved when a scenario gets checkpointed in one of the following ways:

        • If the checkpoint mode is AllGlobals, all global variables defined are saved.

        • If the checkpoint mode is CheckpointStateOnly, the script only saves variables that are part of the checkpointState table. If you remove this value, it defaults to the behavior of saving all globals.

          If you want to change the mode, call setCheckpointMode(AllGlobals) to save all globals or setCheckpointMode(CheckpointStateOnly) to save only those variables in the checkpointState table. They get reinitialized when a checkpointed scenario is loaded.

          vrf:setCheckpointMode(CheckpointStateOnly)

          The following code, from vrfutil.lua, defines some global values:

          -- Global booleans to help define which checkpoint state to use AllGlobals = false

          CheckpointStateOnly = true

          For more information about vrf:setCheckpointMode, please see the VR-Forces Lua documentation.


      4. Editing Scripts While a Scenario is Running

You can add, remove, and edit scripts during scenario creation or while a scenario is running. If a script is not being used by any simulation objects, editing or deleting it has no effect on the scenario. If you change a script that is being executed by a simula- tion object, when you save the change the script may be stopped, restarted, or continue to execute depending on what has changed.

Table 33-2 lists the effect on scripts and scripted tasks running as subtasks if you edit the code or metadata:

image

Table 33-2: Side effects of editing scripts


Change to script Result

Change to script Result

Change code or any metadata except the script ID. Entity type is still supported.

The script restarts. Changes to the Action Cate- gory take effect when the scenario restarts.

Entity types supported changes. The script stops for simulation objects that no

longer support it.

Script ID changes. The script continues to execute. Any script that uses this scripted task as a subtask will fail until its code is updated to use the new script ID.

image


If you changed the simulation object types that can use the script, then it is added to or removed from the menu for the appropriate simulation object types. (This change takes place immediately.)


33.3. Tasks and Subtasks

The primary way that a scripted task carries out actions is through starting subtasks for the simulation object running it or sending tasks to other simulation objects. All C++ tasks and other scripted tasks are available for sending as subtasks or tasks.

If a scripted task needs to give a task to the simulation object that is running it, it does so as a subtask. (The simulation object’s current task is the scripted task itself, so any action that it needs to take is a subtask to the scripted task.) Subtasks are started using the vrf:startSubtask() function.

If a scripted task needs to give a task to a simulation object other than the one running it, it uses the vrf:sendTask() function.

A startSubtask() or sendTask() function specifies the task name and task parameters, if any. The name must be the name of one of the C++ tasks, as listed in the Task page of the Lua API Documentation, or the script ID of another scripted task.

The task parameters are passed as a Lua table, with parameter names as the indices and the parameter values as the values. The valid parameters for C++ tasks are listed in the Lua API documentation. For scripted tasks, the parameter names are the parameter names defined for that task. You can view them by opening a scripted task in the Edit Script dialog box. Any parameters that are not specified when starting the task use their default values.

The following example subtask gives a Move to Waypoint task to the simulation object running the scripted task:

vrf:startSubtask("move-to", {destination = "Waypoint 1"})


image

i

i

If a task does not have any parameters, startSubtask() must represent the parameters as {}. For example:

vrf:startSubtask("wait", {})


image


The following example task sends a Patrol Between Waypoints task to the simulation object named “someEntity”:

vrf:sendTask(someEntity, "patrol-two-points",

{first_control_point="Waypoint 1", second_control_point="Waypoint 2"})

If a task is started with an invalid name or invalid parameters, a runtime error will occur in the script.

Whenever a task or subtask is started, a task ID integer is returned. This task ID is used to monitor or stop the task.


image

i

i

If a task is started on a simulation object that cannot execute it, the task will enter the Complete (failed) state shortly after the start call is made. This may not happen until a subsequent tick of the scripted task.


image

Writing Scripts — Tasks and Subtasks

image

      1. Monitoring the Status of Tasks and Subtasks

        Once a task is started, the scripted task that started it can monitor it using its task ID. A task can be in one of three states: Running, Complete, or Canceled, as follows:

        • Running. The task was started, but has not completed or been canceled.

        • Complete (success). The task has completed, and called endTask(true) to end itself.

        • Complete (failure):

          • The task has ended itself by calling endTask(false).

          • The task failed to start because the simulation object was incapable of executing this task.

        • Canceled:

          • The task was explicitly canceled using stopTask().

          • The task was replaced by a conflicting task.

          • The user issued a Skip Task.


            image

            i

            i

            The success or failure of task completion is defined by the task being executed, and may not be consistent between task types.


            image


            Subtasks are monitored with the functions:

        • isSubtaskComplete(taskID)

        • subtaskResult(taskID)

        • isSubtaskRunning(taskID)

        • isSubtaskCanceled(taskID).

          Tasks are monitored with the functions:

        • isTaskComplete(taskID)

        • taskResult(taskID)

        • isTaskRunning(taskID)

        • isTaskCanceled(taskID).


      2. Stopping Tasks

        Any task or subtask that has been started from a scripted task can be stopped by that task before it has completed. This is done using stopTask(taskID) or stopSub- task(taskID).


      3. Task Parameters

Task parameters are the parameters that are gathered from the user, or set by a parent task, when a task is started. They are passed into the new task when it starts.


For scripted tasks, the task parameters are available in a Lua table named taskParameters available in the global scope. The table contains items named using the parameter names specified in the parameters section of the Scripted Task dialog box when the task was created. The types of these parameters depend on the parameter types selected by the user in this dialog box. Table 33-3 lists the parameter types you can specify when you create a scripted task and the corresponding Lua types in the taskParameters table.

image

Table 33-3: Task parameters and Lua types


Parameter Type Lua Type

Parameter Type Lua Type

Aggregate Formation String

Altitude MSL Number (meters)

Bomb Resource String (resource name)

Boolean Boolean

Choice (List) Number (Index of the option chosen)

Choice (Option Button) Number (Index of option chosen)

DI-Guy Animation String

DI-Guy Appearance String

Distance Number (meters)

Emitter Number (Index of the emitter system) Simulation Object Type String (DIS type enumeration, colon separated) Force String

Heading Number (radians)

Integer Number

Location (with altitude) Location3D

Location (without altitude) Location3D

Munition Resource String (resource name)

Offset Location VectorOffset3D

Real Number

Resource String (resource name)

Simulation Object (Single) SimObject Simulation Objects (Multiple) Table of SimObjects

Speed Number (meters / second)

String String

Time Number (seconds)

Turn Rate Number (radians / second)

image


    1. Geometry

      The Lua interface includes classes representing geometric objects. The classes represent locations and vectors in three dimensional space. Different classes are defined for vectors in different contexts so that functions that manipulate them know what their context is and can convert between contexts automatically. Therefore, a script does not have to, for example, create rotation matrices to perform coordinate transformations between vectors that are in an entity-body context and vectors that are in a world context.


      1. Location3D

        A Location3D represents a point in three-dimensional (3D) space. Scripts can access the three components of the location as latitude, longitude, and altitude. There is no other access to components in any other coordinate system. Methods are available to construct a Location3D, to create a vector from the difference between two locations, and to generate a new point by adding a vector to a location.


      2. Vector3D

        A Vector3D is a direction in a north-east-down coordinate system. Scripts can access these three components of a Vector3D, or access bearing-inclination-range (Figure 33-4). This is the type of vector that scripts will use most often to find directions between locations, to create new locations relative to other locations, and so on.


        image

        North

        North

        image

        Range

        Range

        Bearing


        Inclination



        Down

        East


        Figure 33-3. Vector3D: North-East-Down, or Bearing-Inclination-Range

        When viewed from the perspective of a 3D Cartesian coordinate system that is fixed to the earth, there is no single north-east-down coordinate system. This is because “north” and “east” directions vary depending on where the observer is located on the earth. The Vector3D is therefore similar to a vector in topographic coordinates. At higher latitudes, “north” for two different simulation objects may not be the same direction (for example, two planes near the north pole, but at different longitudes, that are both flying “north,” are not on parallel courses).

        Writing Scripts — Geometry

        image


        Figure 33-3 shows two north-east-down coordinate systems with origins at different locations on the earth. The coordinate systems have different orientations with respect to a coordinate system fixed to the earth.


        image

        North


        East


        Down



        North


        Down East

        Figure 33-4. Coordinate systems with different origins

        A Vector3D is not strictly a vector, in that it is not a straight line in a Cartesian coordi- nate system fixed to the earth. Just as the direction “east” changes (viewed in the Carte- sian coordinate system) to follow the curvature of the earth, so does a Vector3D. This definition is different from topographic coordinates, which are Cartesian coordinates fixed to a point on the surface of the earth. Implications of this definition include the following:

        • The heading of a Vector3D from one location to another is the heading of the shortest route around the earth (the great circle route) between the locations. The length is the great circle distance.

        • The inclination of a Vector3D between two locations with the same altitude is 0.0, even when one location is over the horizon from the other.

        • A Vector3D with length equal to the circumference of the earth, and inclination 0.0, when added to a location on the surface of the earth will produce a location coincident with the first location.


      3. VectorOffset3D

        A VectorOffset3D is a set of three values that define an offset from some reference direc- tion defined by a Vector3D. The three values represent right-forward-up, where:

        • forward is in the same direction as the reference.

        • right is to the right in a horizontal plane. Horizontal means the plane defined by an inclination of zero; this definition implies that the “roll” component of the refer- ence direction is assumed to be zero.

        • up is perpendicular to forward and right, that is, right X forward.

          A VectorOffset3D is appropriate to use, for example, to define the offsets of simulation object formation positions from a central location. Actual formation positions could be generated by transforming the offsets to Vector3Ds using the direction vector of the simulation object, and then adding the Vector3Ds to the simulation object location.


      4. VectorGeoc3D

        A VectorGeoc3D is a vector in a Cartesian coordinate system fixed to the earth (geocen- tric coordinates). The actual coordinate meanings and values are not accessible to the script, because they are considered to be abstract. A VectorGeoc3D can be generated only by taking the difference of two locations, or by transforming a Vector3D at a particular location.

        A VectorGeoc3D between two locations is the line-of-sight vector between the locations. Therefore:

        • A VectorGeoc3D between two points on opposite sides of the earth, at the same alti- tude, will go through the earth. (A Vector3D, by contrast, will go around the earth parallel to the surface.)

        • The angle between two VectorGeoc3D vectors corresponding to north for two simu- lation objects near the north pole will be the difference in their longitudes. (The angle between their Vector3Ds for north, by contrast, will be zero.)

The Lua interface does not have any simulation functions that require VectorGeoc3Ds. However, they may be manipulated to compute angles and so forth.


image

    1. Coding Messages for Translation

      Writing Scripts — Error Detection

      VR-Forces has a utility, translationFileCreate, that can extract the user-visible text in a script dialog box and make it available for translation. (For details, please see “Local- izing the Graphical User Interface,” on page 2-10.) If a script contains messages such as printWarn, printInfo, and so on, you can code these messages so that they are also extracted to the translation file.

      To code messages for translation, use the following syntax:

      printWarn(vrf:trUtf8("Text message."))

      You can include variable data in the message, as follows:

      printWarn(vrf:trUtf8("Some text %1. Some more text

      %2):arg(variable1):arg(variable2))

      where an argument can be a string or number.

      For more information about coding for translation, please see the !HowToPrint page in the Lua documentation (./doc/luadoc/index.html).


    2. Error Detection

      The VR-Forces Lua implementation can detect syntax errors and runtime errors.

      When you save a script, it is checked for syntax errors. If an error is found, it is reported in an error message. In Figure 33-5, the if statement in line 7 is missing the then keyword.


      image

      Figure 33-5. Lua syntax error


      image

      i

      i

      Detection of a syntax error does not prevent the script from being saved. If you do not fix the error and try to use the script, the back-end generates an error.


      image

      Writing Scripts — Error Detection

      image


      When you run a script, the back-end can detect errors due to incorrect use of user func- tions and the Lua API functions, such as calling an object that does not exist, or trying to access feature data before it is paged in. When a runtime error is detected, the back- end generates an error message. When the back-end generates an error, the script that caused the error is displayed in bold, red type in the Scripts dialog box (Figure 33-6). Therefore, you may want to keep the dialog box open while you are testing new or edited scripts.


      image

      Figure 33-6. Lua error message

      To view an error message:

      1. In the Scripts dialog box, select the script that has generated an error.

      2. Choose Script View Script Error. An error message is displayed.


        image

        i Script errors are also sent to the console in the Information dialog box.

        image


    3. Interactive Scripts

      You can write scripts that request input from the VR-Forces user. Script questions are sent to the simulation object’s object console and to the Object Console Summary Panel. Users can answer questions from the Object Console Summary Panel.

      To create interactivity in a script, use the vrf:askUserQuestion() Lua function. When a script sends a question to the console, the Answer Questions button becomes active.

      When the user clicks the button, a set of choices is displayed. The choices can be presented as buttons, as option buttons, or as a drop-down list.

      The script can do whatever it wants with the user input.


    4. A Basic Scripted Task

VR-Forces includes many scripted tasks, all of which can serve as examples of how to write one. The Create and Move to Waypoint scripted task is a basic example that shows you how to:

The Lua code is comprehensively commented. This section supplements the comments.


      1. Create and Move to Waypoint Metadata

        Figure 33-7 shows the metadata for the Create and Move to Waypoint scripted task.


        image

        Figure 33-7. Create and Move to Waypoint script

        To view the metadata:

        1. Choose Simulation Scripts. The Scripts dialog box opens.

        2. Expand the Examples folder (Figure 33-8).


          image

          Figure 33-8. Scripts dialog box

        3. Select Create and Move to Waypoint.

        4. Choose Script Edit Script Meta Data. The Edit Script dialog box opens (Figure 33-7).

          Note how the Name column of the Create and Move to Waypoint entry in the Scripts dialog box matches the Menu Text in the Edit Script dialog box. The Script ID and Description fields are also drawn from the scripted tasks metadata.

          Now let’s look at the parameters. This scripted task has two parameters, waypointLoca- tion and orderedSpeed. To see the definition of a parameter, select it and click the Edit button image). Figure 33-9 shows the dialog boxes that specify the parameters.


          image image

          Figure 33-9. Parameter definitions


          Figure 33-10 shows the dialog box that is displayed when you assign a simulation object this task. Note that the description of the task on the dialog box matches the descrip- tion in the metadata. The parameter labels in the dialog box match the labels specified for the two parameters. The labels are not the same thing as the parameter name. The parameter name is the name used in the Lua script for this scripted task.


          image

          Figure 33-10. Create and Move to Waypoint dialog box

          When this scripted task is assigned to a simulation object, the user will specify the waypoint and the ordered speed. Then the scripted task executes. Now we will look at the Lua script to see what happens.


      2. The Create and Move to Waypoint Lua Script

The entire Lua script for this scripted task (without comments) is as follows:

require "vrfutil" moveToWaypointSubtaskId = -1 function init()

vrf:setTickPeriod(0.5)


waypoint = vrf:createWaypoint({location=taskParameters.waypointLocation, force=this:getForceType()})


vrf:sendSetData(this, "set-speed",

{speed=taskParameters.orderedSpeed})

end

function tick()

if moveToWaypointSubtaskId == -1 then moveToWaypointSubtaskId = vrf:startSubtask("move-to",

{control_point=waypoint})

end

if vrf:isSubtaskComplete(moveToWaypointSubtaskId) then vrf:endTask(true)

end end

function shutdown() vrf:deleteObject(waypoint)

end


The comments in the script describe the control flow. The essence is that using the input from the task dialog box, the waypoint gets created and the speed gets set in init(). The first time the task is ticked, it sends the Move to Waypoint subtask. There- after, each time the task is ticked, it checks to see if the subtask is complete. When the subtask is complete, the task is ended and the waypoint is removed.

The functions in this script are all in the vrf class, which is described in “Lua Classes,” on page 33-3. The createWaypoint() function takes its location from the waypointLo- cation parameter that was defined in the scripted task metadata and whose value was provided in the Create and Move to Waypoint dialog box when the task was assigned. Similarly, the ordered speed is set with the sendSetData() function and the value is taken from the orderedSpeed parameter for the task. The script gets the parameter values with the taskParameters.parameter syntax.

This script uses three of the entry point functions – init(), tick(), and shutdown(). If you were to checkpoint the scenario while the script was executing, the standard save actions would take place, but no script-specific actions would be taken, because there is no saveState() function in the script. Similarly, no special action would be taken when the scenario was loaded again because loadState() is not used.

For details about the parameters and return values of the functions, please see the VR- Forces Lua API documentation. Similarly, the tasks and set data requests that you can assign with the startSubtask() and sendSetData() functions are described on the Task and Set pages of the Lua API documentation. You should review the lists of functions to see what you can do in a scripted task.

Writing Scripts — A Simple Scripted Set

image

    1. A Simple Scripted Set

      This example script shows how to create a scripted set. It takes two input values from a dialog box using setParameters. Then it uses the sendSetData() function to set the values for the entity. It needs an endSet() function to finish the process.

      require "vrfutil" function init()

      vrf:setTickWhilePaused(true) vrf:setTickPeriod(0.5)


      end

      function tick()

      vrf:sendSetData(this, "set-speed", {speed=setParameters.setSpeed}) vrf:sendSetData(this, "set-force", {force=setParameters.setForce}) vrf:endSet()

      end

      The following scripted task does exactly the same thing as the scripted set. It sets the speed and force of the selected simulation object. The difference is that since this is a scripted task, it interrupts the task that the simulation object is executing. Try these two scripts to see the difference.

      require "vrfutil" function init()

      vrf:setTickWhilePaused(true) vrf:setTickPeriod(0.5)


      end

      function tick()

      vrf:sendSetData(this, "set-speed", {speed=taskParameters.setSpeed}) vrf:sendSetData(this, "set-force", {force=taskParameters.setForce}) vrf:endTask()

      end


      image

      i

      i

      As you can see there is nothing in the scripts that identifies them as a scripted task or scripted set. VR-Forces determines the type of script from the myScriptType value in the metadata. Scripted task types are defined in

      ./include/vrfutil/scriptedTaskMetaData.h.


      image


      image

    2. A Simple Reactive Task

      Writing Scripts — A Simple Reactive Task

      The difference between a scripted task and a reactive task is the use of the check() and checkInit() functions in the reactive task. The check() function tests a condition at whatever tick rate you specify. If the condition returns true, the task runs.

      The simple reactive task in this section monitors the speed of a simulation object. When it exceeds 15 meters per second, the simulation object is destroyed. The script works as follows:

      1. The checkInit() function sets the tick rate to 1.0 second.

      2. In check(), VR-Forces gets the speed of the simulation object and prints it to the console.

      3. It tests to see if the speed is greater than 15 meters per second. If the condition is met, the function returns true.

      4. If the function returns true, the script executes init() and begins to tick().

      5. In the tick() function, the simulation object is destroyed and the task is complete. Note that in the executeSetData() function, set-destroy does not have parameters, but the command must include empty braces.

        function checkInit() vrf:setTickPeriod(1.0)

        end


        function check()

        currentSpeed = this:getSpeed() print("speed is:", currentSpeed) if currentSpeed > 15 then

        return true end


        return false end


        function init() vrf:setTickPeriod(0.5)

        end


        function tick()

        vrf:executeSetData("set-destroy", {}) vrf:endTask(true)

        end

        Writing Scripts — Background Processes

        image

    3. Background Processes

Background processes are scripts that run continuously in the background. When you create a background process, you specify which simulation object types it is valid for. Thereafter, whenever you create those simulation object types the background process initializes as soon as the simulation object is created. The supported simulation object type can be as general or as specific as you want it to be, based on the entity type enumeration that you specify.

Background processes are used for simulation object actions that happen continuously in a scenario, such as consuming or receiving supplies, calculating the simulation object’s footprint, and automatically attacking opposing forces.

Background processes have one important restriction - they cannot issue tasks to simu- lation objects or stop their tasks.

There is no indication in the GUI that a background process is running. The only way to know which background processes are available and which simulation objects they might be affecting is to examine them in the Scripts dialog box.

The following code is a very simple background process that checks a simulation object’s speed every five seconds. If the speed exceeds three meters/second, it prints a message to the console. The script’s metadata specifies that it applies to lifeforms.

Therefore, this background process will run for each lifeform entity in the scenario.

require "vrfutil" function init()

vrf:setTickPeriod(5.0) end


function tick()

currentSpeed = this:getSpeed() if currentSpeed > 3 then

print("speed is:", currentSpeed, ". Going too fast.") else

print ("Speed is OK." end

end


image

34. Setting the State of Simulation Objects


This chapter explains how to set simulation object state, such as speed, force, and target.

Setting Simulation Object State and Attributes 34-4

Active Sonar Mode 34-5

Activity 34-6

Aiming 34-7

Altitude 34-8

Ammunition 34-8

Ammunition Pacing/Tracking 34-9

Appearance 34-10

Armed 34-11

Capabilities 34-11

Collision Avoidance Types 34-12

Concealed 34-13

Contamination 34-13

Counter Measures Auto Launch 34-13

Current Speed 34-14

Destroyed 34-14

Detonation Fuse Type 34-15

DI-Guy Characteristics (Appearance, Head, Body Weight) 34-16

DI-Guy Hand Item 34-16

Disembarked 34-17

Embarked 34-17

image

Setting the State of Simulation Objects

Emitter 34-18

Engagement Results 34-19

Equipment Pacing/Tracking 34-20

Food, Water, Fuel, Oil and Lubricant 34-20

Food, Water Fuel, Oil and Lubricant Pacing/Tracking 34-21

Force 34-21

Formation 34-22

Heading 34-23

Health 34-23

IFF 34-24

Invulnerable 34-25

Jam Targets 34-25

Lase Autonomous 34-25

Laser Code 34-26

Location 34-26

MOPP Level 34-27

Morale 34-27

Navigation Preferences 34-28

Notify Level 34-28

Ordered Speed 34-29

Percent Complete 34-29

Posture (Unit) 34-31

Posture (Human) 34-32

Preferred Targets 34-33

Radar Mode 34-34

Reorganize 34-34

Resources 34-35

Resources Pacing/Tracking 34-35

Restore 34-36

Resupply Mode 34-36

Rules of Engagement 34-37

How Fire-When-Fired-Upon Works 34-37

Sector of Responsibility 34-38

Sensor Aim 34-39

Sensor Enabled 34-39

image

Setting the State of Simulation Objects

Sensor Zoom 34-40

Sonar Depth 34-41

Spot Reports 34-42

Superior 34-43

Supplying 34-43

Surrendered 34-43

Synchronize Laser Code 34-44

Target 34-44

Tasked by Superior 34-45

Tracer Use 34-45

Unit State 34-45

Weapons Pacing/Tracking 34-46

Setting the State of Simulation Objects — Setting Simulation Object State and Attributes

image

    1. Setting Simulation Object State and Attributes

      image

      image

      Some set data requests only apply to entity-level scenarios. Others only apply to aggre- gate-level scenarios. These set data requests indicate the applicable simulation type with an entity ( ) or unit ( ) icon in the margin.

      The Set menu is context sensitive. It only shows the options that apply to the selected simulation object.

      The graphical user interface does not necessarily know about the state of a simulation object. When you open a dialog box for a Set command, any data in the dialog box represents either default values or the most recently used value, except for the Altitude, IFF, Location, and Heading dialog boxes, which show the current values for the selected simulation object.


      image

      i

      i

      You can check the current status of most simulation object state data in the Information dialog box.


      image


      You can filter simulation object selection lists. For details, please see “Filtering the Object Selection Lists,” on page 26-10.

      The instructions for setting simulation object state direct you to use options on the Set menu. However, all the options available on the main menu are also available on context-sensitive menus. A limited number of tasks are available on the Sets Toolbar and on the Last Selected Objects Panel.

      You can also set the state of tactical graphics. For details, please see Chapter 40, Setting the State of Tactical Graphics.

      Setting the State of Simulation Objects — Active Sonar Mode

      image

      image

    2. Active Sonar Mode

      If an entity has an active sonar system, you can set the sonar mode.


      image

      i RPR FOM 1.0 does not support active sonar.

      image

      To set the active sonar mode:

      1. Select the entity.

      2. Choose Set Sensors Active Sonar Mode. The Active Sonar Mode dialog box opens.

      3. In the System ID list, select the sonar system that you are setting. The entities provided with VR-Forces just have one active sonar system.

      4. In the Mode list, select a sonar mode or select Off to disable active sonar.

      5. Click OK.

      Setting the State of Simulation Objects — Activity

      image

      image

    3. Activity

      You can give a simulation object in an aggregate-level scenario an activity. Activities are configured by simulation object type, so they may vary from one simulation object to another. Some of the available activities include the following:

      • Unknown

      • Attacking

      • Bivouacking

      • Emplacing obstacle

      • Indirect fire

      • Jamming

      • Other

      • Patrolling

      • Probing

      • Retreating.

        To specify an activity:

        1. Select the simulation object.

        2. Choose Set Disposition Activity. The Activity dialog box opens.

        3. Select an activity from the list.

        4. Click OK.


        image

        image

    4. Aiming

      Setting the State of Simulation Objects — Aiming

      The Aiming set data request tells an entity to aim at a point, an object, or an angle. It does not cause the entity to shoot. If the entity acquires a target, it aims at the target and fires. Then it returns to the aiming behavior specified by the set data request.

      An entity can move while it is aiming. If an entity is moving and it can no longer reasonably aim in the specified direction, it stops aiming. For example if the entity is aiming at a point and the entity’s movement causes the point to be behind it, the entity stops aiming (unless it has a turret that can aim in that direction). If the entity stopped aiming while it was moving, when it stops moving, it turns to aim in the specified way.

      You can also use this set data request to stop the aiming behavior.

      To have an entity aim at a location or object:

      1. Select the entity.

      2. Choose Set Engagement Aiming. The Aiming dialog box opens.

      3. Select the aiming option you want.

      4. Specify the appropriate parameter for the aiming choice:

        • Aim at Point – specify the location.

        • Aim at Object – select the object.

        • Aim at Angle – specify the azimuth and elevation.

        • Cease Aiming – no parameters required.

      5. Click OK.

      Setting the State of Simulation Objects — Altitude

      image

      image

    5. Altitude

      The Altitude request changes the altitude of simulation objects immediately. If you want a fixed-wing or rotary-wing entity to move to an altitude, use the Move to Alti- tude or Fly Altitude task. You can set the altitude manually or place an entity at a specific level in a multi-level terrain feature, such as a building.

      To set an entity’s altitude:

      1. Select the entity.

        image

      2. Choose Set Position Altitude, or click the Altitude button ( ) on the Sets Toolbar. The Altitude dialog box opens. It displays the entity’s current altitude.

      3. Select MSL (mean sea level) or AGL (above ground level) to specify the base for the altitude value.

      4. Type the new altitude.

      5. Click OK.


      image

    6. Ammunition

      You can specify the amount of each type of ammunition that a simulation object in an aggregate-level scenario has.

      To set the ammunition level:

      1. Select the simulation object.

      2. Choose Set Disposition Ammunition. The Ammunition dialog box opens.

      3. Select the check box for each type of ammunition that you want to set.

      4. For each selected type of ammunition, adjust the slider or type a value.

      5. Click OK.

      Setting the State of Simulation Objects — Ammunition Pacing/Tracking

      image

      image

    7. Ammunition Pacing/Tracking

      Ammunition Pacing/Tracking lets you specify that a particular ammunition type be marked as pacing, tracking, or neither. Pacing indicates that the status of this item is critical to the mission. Tracking indicates that the commander is interested in the status of this item. These designations do not affect the simulation. They are reported for use by external systems.

      To specify pacing or tracking for a unit’s ammunition:

      1. Select the simulation object.

      2. Choose Set Disposition Ammunition Pacing/Tracking. The Ammunition Pacing/Tracking dialog box opens.

      3. Select the check box for each type of ammunition for which you want to specify pacing or tracking.

      4. For each selected ammunition type, select an option from the list.

      5. Click OK.

      Setting the State of Simulation Objects — Appearance

      image

      image

    8. Appearance

      You can set appearance attributes for simulation objects. The appearance attributes that are available for a simulation object are determined by its entry in

      ./appData/settings/vrfGui/SISO-REF-010-2010-RC1.xml. The default list of appearance

      attributes is based on the DIS standard.

      The Lifeform State field of the Appearance dialog box sets the posture for an entity. If VR-Forces does not support a selected posture, it simulates the entity using the closest similar posture. If a posture involves walking or running, VR-Forces chooses the posture to use based on the entity’s speed. For more information about setting posture, please see “Posture (Human),” on page 34-32.

      If you want to set the appearance of a human character, use the DI-Guy Appearance set data request, described in (“DI-Guy Characteristics (Appearance, Head, Body Weight),” on page 34-16).


      image

      i

      i

      In aggregate-level scenarios, the Appearance set data request is included in the list of commands for the Send Radio Set task and the list of commands available on the Command menu in plans. However, it is not supported and if used, will fail. Its presence is due to the lack of context sensitivity for these menus.


      image


      To set appearance values:

      1. Select the simulation object.

      2. Choose Set Appearance Appearance. The Appearance dialog box opens. The settings displayed are the current settings for the simulation object.

      3. Change appearance settings as desired.

      4. Click OK.


      image

      image

    9. Armed

      Setting the State of Simulation Objects — Capabilities

      IEDs, car bombs, and suicide bombers must be armed to detonate. They are all armed by default. You can disarm them and re-arm them.


      image

      i

      i

      IEDs, car bombs, and suicide bombers have radios. Therefore, you can arm and disarm them using the Send Radio Set task.


      image


      To arm or disarm an explosive device:

      1. Select the explosive device.

      2. Choose Set Engagement Armed. The Armed dialog box opens.

      3. Select an option from the list.

      4. Click OK.


    10. Capabilities

      The capabilities that are available for a simulation object are determined by its entry in

      ./appData/settings/vrfGui/SISO-REF-010-2010-RC1.xml. The default list of capabilities is based on the DIS standard.

      To set simulation object capabilities:

      1. Select the simulation object.

      2. Choose Set Disposition Capabilities. The Capabilities dialog box opens. It displays the current settings for the simulation object.

      3. Change the settings you want to change.

      4. Click OK.

      Setting the State of Simulation Objects — Collision Avoidance Types

      image

      image

    11. Collision Avoidance Types

      Sometimes entities exhibit undesired collision avoidance behavior because they try to avoid objects that are close to their line of travel, but not necessarily blocking it. You can enable and disable avoidance of entities, buildings, and trees on a per-entity basis. This option overrides the collision avoidance settings in the object parameter database entry for the entity.


      image

      i

      i

      • Collision avoidance settings are saved in an entity’s process state reposi- tory. However, there is no indication in the GUI what these settings are. Therefore, we recommend that you not change collision avoidance settings through the GUI indiscriminately because you may lose track of which entities are avoiding which types of objects. To permanently set collision avoidance for an entity, edit its components in the object parameter database.

      • When the Collision Avoidance Types dialog box opens, it does not reflect the settings for the selected entities. It only provides a default setting. Make sure that you review all the settings in the dialog box to be sure you do not inadvertently enable or disable a setting that you do not want to change.

      • The Collision Avoidance Types set data request lets you specify collision avoidance only for broad categories of objects. You can set collision avoidance more specifically in the object parameter database.


        image


        To change collision avoidance for specific object types:

        1. Select an entity.

        2. Choose Set Action Collision Avoidance Types. The Collision Avoidance Types dialog box opens.

        3. Select the check boxes for object types to avoid and clear the check boxes for the object types that the entity should not try to avoid.

        4. Click OK.

        Setting the State of Simulation Objects — Counter Measures Auto Launch

        image

    12. Concealed

      The Concealed request sets a simulation object’s concealment attribute to True or False. For entity-level scenarios, this only affects the DIS or RPR FOM data sent over the network. It does not affect the simulation. For aggregate-level scenarios, when a simula- tion object is concealed, its sensor signature is changed so that it is harder to detect.

      To set the concealment attribute for a simulation object:

      1. Select the simulation object.

      2. Choose Set Disposition Concealed. The Concealed dialog box opens.

      3. Select an option from the list.

      4. Click OK.


      image

    13. Contamination

      The Contamination set data request lets you set the contamination type for a simula- tion object.

      To set contamination:

      1. Select the simulation object.

      2. Choose Set Disposition Contamination. The Contamination dialog box opens.

      3. Select a contamination type from the list.

      4. Click OK.


      image

    14. Counter Measures Auto Launch

      The Counter Measures Auto Launch set data request lets you enable and disable auto- matic launching of counter measures. If you disable automatic counter measures, you can still launch them manually using the Launch Counter Measures task.

      To enable or disable automatic launch of counter measures:

      1. Select the entity.

      2. Choose Set Engagement Counter Measures Auto Launch. The Auto Launch dialog box opens.

      3. Select an option from the list.

      4. Click OK.

      Setting the State of Simulation Objects — Current Speed

      image

    15. Current Speed

      The Current Speed set data request sets the speed of a simulation object immediately and changes the ordered speed to this new speed value. By contrast, Ordered Speed (“Ordered Speed,” on page 34-29) causes a simulation object to accelerate or decelerate to the desired speed.

      A negative value causes the entity to go backwards if it supports backwards movement.


      image

      i

      i

      For all simulation objects except humans and fixed-wing aircraft that are in the air, if you set the current speed and the object does not have a task, it begins to move at that speed and then slows down until the speed reaches 0. Fixed-wing aircraft that are in a default orbit mode change their speed to the new current speed. Humans might take a step, but then will stop moving.


      image


      To set current speed:

      1. Select the simulation object.

      2. Choose Set Action Current Speed. The Current Speed dialog box opens.

      3. In the Current Speed text box, set the speed.

      4. Click OK.


    16. Destroyed

      You can set a simulation object’s state to be destroyed. This can be helpful when you want a simulation object to be destroyed without having to first simulate its destruction by another simulation object.

      To set a simulation object’s state to destroyed:

      1. Select the simulation object.

      2. Choose Set Disposition Destroyed. The simulation object is immediately destroyed.

      Setting the State of Simulation Objects — Detonation Fuse Type

      image

      image

    17. Detonation Fuse Type

      The Detonation Fuse Type set data request lets you configure detonation of improvised explosive devices (roadside IED entity), suicide bombers, and car bombs. You can set them to detonate immediately, at a certain time delay, or based on the proximity of a target entity. If you specify proximity detonation, you can set the radius of the proxi- mate area. If you specify time, you must set the time in seconds until detonation. Deto- nation Fuse Type implicitly arms the device. (For details about arming devices, please see “Armed,” on page 34-11.)


      image

      i

      i

      IEDs, car bombs, and suicide bombers have radios. Therefore, you can detonate them using the Send Radio Set task.


      image


      To configure detonation fuse type:

      1. Select the object that you want to configure.

      2. Choose Set Engagement Detonation Fuse Type. The Detonation Fuse Type dialog box opens.

      3. In the Fuse Type list, select the fuse type (Timed, Immediate, or Proximity).

      4. If you selected a Timed fuse, in the Time box, specify the elapsed time, in seconds, at which the IED should detonate.

        If you selected a Proximity fuse, in the Proximity box, specify the radius of the area in which a simulation object will trigger the detonation.

      5. Click OK.

      Setting the State of Simulation Objects — DI-Guy Characteristics (Appearance, Head, Body Weight)

      image

    18. DI-Guy Characteristics (Appearance, Head, Body Weight)

      The DI-Guy Characteristics set data request determines the clothing and physical char- acteristics of a lifeform when it is displayed in a 3D simulation that uses DI-Guy char- acters.


      image

      i The DI-Guy Characteristics set data request applies only to lifeform entities.

      image

      To set an entity’s DI-Guy appearance, head, or body weight:

      1. Select the entity.

      2. Choose Set Appearance DI-Guy Characteristics. The DI-Guy Characteristics dialog box opens.

      3. Optionally, in the 3D view only, select the Apply Selected Appearance Immediately check box. This displays the selected entity with the new appearance so that you can see what it looks like before you apply the change.

      4. Optionally, filter the appearance list by choosing options in the various filter lists.

      5. To change the appearance, select an appearance from the DI-Guy Appearance list.

      6. To change the head, select an option in the DI-Guy Head list.

      7. To change the weight of the character, slide the DI-Guy Body Weight slider or change the value in the text box (the range is 0.5 - 5.0).

      8. Click OK.


      image

    19. DI-Guy Hand Item

      The DI-Guy Hand Item set data request lets you change the hand item that a character has. DI-Guys can have a variety of hand items. For example, a civilian can have a cell phone, a pistol, or a camcorder, while a soldier can have a variety of weapons.

      To set a DI-Guy’s hand item:

      1. Select the entity.

      2. Choose Set Appearance DI-Guy Hand Item. The DI-Guy Hand Item dialog box opens.

      3. Select a hand item from the list.

      4. Optionally, in the 3D view only, select the Apply Selected Hand Item Immediately check box. This displays the selected entity with the new hand item so that you can see what it looks like before you apply the change.

      5. Click OK.


      image

    20. Disembarked

      Setting the State of Simulation Objects — Embarked

      The Disembarked set data request immediately disembarks a simulation object (as opposed to simulating disembarkation, as done by the Disembark task). It is the equiv- alent of the Objects Disembark command. However, Disembarked allows you to include immediate disembarkation in a plan.

      To set a simulation object to be disembarked:

      1. Select the simulation object. (If you are using the 2D icon model, embarked simu- lation objects are not displayed, so you have to select it in the Objects List Panel.)

      2. Choose Set Embarkation Disembarked.


    21. Embarked

      The Embarked set data request immediately embarks a simulation object (as opposed to simulating embarkation, as done by the Embark task). It is the equivalent of the Objects

      Embark On command. However, Embarked allows you to include immediate embar- kation in a plan.

      The default location for this set data request is the center of the parent simulation object (0,0,0). It does not use preconfigured slots like the Embark task does. If you are using a Stealth observer mode and want placement of embarked simulation objects to look good, you will have to calculate offsets for each simulation object you embark.


      image

      !

      !

      If you are using HLA and want to use the embarkation feature, you must use RPR FOM 2, draft 17 or later.


      image


      To set a simulation object to be embarked:

      1. Select the simulation object to be embarked.

      2. Choose Set Embarkation Embarked. The Embarked dialog box opens.

      3. Select the simulation object to embark on.

      4. Optionally, specify a embarkation offset.

      5. Click OK.

      Setting the State of Simulation Objects — Emitter

      image

    22. Emitter

      The Emitter set data request enables or disables emitters on simulation objects that have them.

      The radar sensor has an emitter component that models basic electromagnetic emis- sions. A simulation object can have multiple emitter components. Each emitter compo- nent can have a list of modes and each mode can have multiple beams.

      Emission properties (azimuth, elevation, effective radiated power, and so on) for each beam are specified in the emitter component descriptor in the object parameter data- base. Emission properties are published by the emitter component.

      An emitter component can publish itself as a standard beam type or a tracking beam type. The type is determined by the setting for the targeting-capable parameter in the object parameter database. It applies to all beams emitted by the specific component. If targeting-capable is False, the beam is a standard beam. If targeting-capable is True, it is a tracking beam.

      If an emitter component has targeting-capable set to True, it registers for set-target messages. If you set a target for the simulation object on which the emitter is mounted, it publishes the target entity as its tracking target for all of the components beams.


      image

      i

      i

      • Setting a target does not cause the beam to actually track the target. The beam’s behavior is determined by the parameters in its description in the object parameter database.

      • The emitter continues to publish the targeted entity as its tracking target until you set another target, regardless of the status of that entity in the exercise. There is no way to set the target to “none”.

      • Please see “Configuring Emitters,” on page 74-2, for an explanation of how to configure individual and multiple emitters in the object param- eter database.

      • Please see the online help for the OPD Editor for a description of emitter parameters.


        image


        Each emitter has an ID that is assigned automatically, starting with 0. Unless you change the system definition files, all default fixed-wing aircraft have one emitter with ID 0.

        Setting the State of Simulation Objects — Engagement Results

        image


        To turn on electromagnetic emissions:

        1. Select the simulation object.

        2. Choose Set Sensors Emitter. The Emitter dialog box opens.

        3. Type the emitter ID. If the simulation object only has one emitter, its ID is 0. If it has more than one emitter, IDs get incremented by 1 for each additional emitter. There is no way to identify the emitter ID for a particular emitter, so you will have to use a trial-and-error approach to identify the correct emitter ID to use.

        4. In the Emitter list, select On.


        image

    23. Engagement Results

      An engagement result is a a text string that gets included in entity state update messages that get sent over the network. The purpose is for a human participant to comment on the current state of a simulation object as a simulation progresses. Once specified, the text string continues to get sent until the expiration time is reached or a new engage- ment result is set.

      To set engagement results:

      1. Select the simulation object.

      2. Choose Set Engagement Engagement Results. The Engagement Results dialog box opens.

      3. Specify the engagement result. This can be any text you want to enter.

      4. Set the expiration time in days and hours:minutes:seconds.

      5. Click OK.

      Setting the State of Simulation Objects — Equipment Pacing/Tracking

      image

      image

    24. Equipment Pacing/Tracking

      Equipment Pacing/Tracking lets you specify that a particular type of equipment be marked as pacing, tracking, or neither. Pacing indicates that the status of this item is critical to the mission. Tracking indicates that the commander is interested in the status of this item. These designations do not affect the simulation. They are reported for use by external systems.

      To specify pacing or tracking for a unit’s equipment:

      1. Select the simulation object.

      2. Choose Set Disposition Equipment Pacing/Tracking. The Equipment Pacing/Tracking dialog box opens.

      3. Select the check box for each type of equipment for which you want to specify pacing or tracking.

      4. For each selected ammunition type, select an option from the list.

      5. Click OK.


      image

    25. Food, Water, Fuel, Oil and Lubricant

      You can set the resources for a simulation object in an aggregate-level scenario.

      To set the level of food, water, fuels, and lubricants:

      1. Select the simulation object.

      2. Choose Set Disposition Food, Water, Fuel, Oil and Lubricant. The Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant dialog box opens.

      3. Select the check box for each type of resource you want to specify.

      4. For each selected resource type a value.

      5. Click OK.

      Setting the State of Simulation Objects — Force

      image

      image

    26. Food, Water Fuel, Oil and Lubricant Pacing/Tracking

      Food, Water, Fuel, Oil, and Lubricant Pacing/Tracking lets you specify that a particular resource be marked as pacing, tracking, or neither. Pacing indicates that the status of this item is critical to the mission. Tracking indicates that the commander is interested in the status of this item. These designations do not affect the simulation. They are reported for use by external systems.

      To set pacing and tracking for food, water, and fuels, and lubricants:

      1. Select the simulation object.

      2. Choose Set Disposition Food, Water, Fuel, Oil and Lubricant Pacing/Tracking. The Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant Pacing/Tracking dialog box opens.

      3. Select the check box for each type of resource for which you want to specify pacing or tracking.

      4. For each selected resource select an option from the list.

      5. Click OK.


    27. Force

      You can change a simulation object’s force during runtime. This might be useful in a simulation in which neutral forces begin assisting one force or another, or in which opposing forces capture friendly force weaponry and begin using it. You can also set the force for combat engineering objects in aggregate-level scenarios.

      When you change a simulation object’s force, its:

      • Echelon ID changes to reflect the new force.

      • Icon changes to the appropriate force color and type.

      • Force ID changes.

        The entity enumeration does not change.

        To set the force of a simulation object:

        1. Choose Set Disposition Force. The Force dialog box opens.

        2. Select a force from the list.

        3. Click OK.

        Setting the State of Simulation Objects — Formation

        image

        image

    28. Formation

      VR-Forces supports the following formations:

    29. Heading

      Setting the State of Simulation Objects — Health

      The Heading request instantly sets a simulation object’s heading. If you want a simula- tion object to move to a new heading by pivoting or executing a K-turn, use the Turn To Heading task. You can also set a simulation object’s heading manually. For details, please see “Specifying an Object’s Heading Dynamically,” on page 16-17.

      To set a simulation object’s heading:

      1. Select the simulation object.

        image

      2. Choose Set Position Heading, or click the Heading button ( ) on the Sets Toolbar. The Heading dialog box opens. It displays the simulation object’s current heading.

      3. In the Heading text box, type a heading, in degrees.

      4. In the Relative To list, select one of the following options:

        • North. Turn to the specified absolute heading.

        • Current Heading. Turn the specified number of degrees relative to the current heading.

        • Host (if embarked). If embarked, turn to the specified heading relative to the host simulation object.

      5. Click OK.


      image

    30. Health

      Health is a value based on a simulation object’s total personnel, equipment, and weapons. The Health set data request lets you restore personnel to their full values and set the overall health of the simulation object. For details about simulation object health, please see “The Aggregate Warfare Model,” on page 23-2.

      To set a simulation object’s health:

      1. Select the simulation object.

      2. Choose Set Disposition Health. The Health dialog box opens. It displays the current state of personnel, equipment, and weapons.

      3. To restore all personnel, select Reset Kill, Captured, Wounded, Missing.

      4. To specify the overall health of the simulation object, adjust the Health slider or type a number in the Health box. As you move the slider to the left, the amount of personnel, equipment, and weapons decreases.

      5. Click OK.

      Setting the State of Simulation Objects — IFF

      image

    31. IFF

      Friendly fixed-wing entities can model a NATO Identification Friend from Foe (IFF) transponder.


      image

      i Mode 5 and mode C are equivalent.

      • The dialog box does not force you to enter valid codes. It truncates

        invalid entries to the correct length (but not necessarily valid data).

      • When you open the dialog box, it reflects the current IFF settings for the entity, if any.

      • You can view an entity’s IFF settings on the IFF tab of its Information dialog box.


      image


      To set the IFF transponder for a fixed-wing entity that is configured with an IFF controller:

      1. Select the entity.

      2. Choose Set Sensors IFF. The IFF dialog box opens (Figure 34-1).


        image

        Figure 34-1. IFF dialog box

      3. Complete the IFF dialog box.


      image

      image

    32. Invulnerable

      Setting the State of Simulation Objects — Lase Autonomous

      If a simulation object is invulnerable, it does not take damage from munitions.

      To set a simulation object to be invulnerable:

      1. Select the entity.

      2. Choose Set Disposition Invulnerable. The Invulnerable dialog box opens.

      3. Select an option from the list.


    33. Jam Targets

      The Jam Targets set data request orders an aircraft to jam specific targets or all simula- tion objects within its jamming beam. This set data request does not affect the simula- tion. It sends update messages that can be used by other applications in a simulation.

      To jam targets:

      1. Select the entity that will send out the jamming beam.

      2. Choose Set Sensors Jam Targets. The Jam Targets dialog opens.

      3. In the Mode group box, select All Entities in Beam or Selected Entities.

      4. If you selected Selected Entities, select the targets you want to jam.

      5. Click OK.


      image

    34. Lase Autonomous

      By default, entities with laser capability lase targets autonomously as part of the built-in target acquisition and firing process. You can specifically enable and disable autono- mous lasing.

      To enable or disable autonomous lasing:

      1. Select the entity.

      2. Choose Set Laser Designator Lase Autonomous. The Lase Autonomous dialog box opens.


        image

        i

        i

        The Lase Autonomous dialog box does not show the current lasing state of the entity.


        image


      3. Select an option from the list (Off or On).

      4. Click OK.

      Setting the State of Simulation Objects — Laser Code

      image

      image

    35. Laser Code

      The Laser Code set data request sets the code for laser beams sent by an entity and the code that the entity’s missiles seek when they fire. By default, VR-Forces calculates a laser code for each laser-capable entity when it is created. You can change the laser code to a code of your choice. For information about the consequences of setting laser codes, please see “Lasing Targets,” on page 9-15.

      To specify an entity’s laser code:

      1. Select the entity.

      2. Choose Set Laser Designator Laser Code. The Laser Code dialog box opens.

      3. Type a number between 111 and 8888, using only the digits 1-8.

      4. Click OK.


    36. Location

      To move a simulation object instantly from one place to another, you can set its loca- tion or you can drag it to a new location. For information about dragging simulation objects, please see “Dragging an Object to a New Location,” on page 16-19. For ground entities, specifying an altitude lets you place an entity at different levels (floors) in building features.

      To set the location for a simulation object:

      1. Select the simulation object.

      2. Choose Set Position Location. The Location dialog box opens. It displays the simulation object’s current location. The cursor changes to input mode.

      3. Click on the terrain where you want to move the simulation object, or enter the coordinates of the location in the Location dialog box.

      4. Optionally, set the altitude, as described in “Specifying an Object’s Altitude,” on page 16-14.

      5. Click OK.


      image

      image

    37. MOPP Level

      Setting the State of Simulation Objects — Morale

      When you set a unit’s MOPP level, the MOPP level changes instantly. To change MOPP level over time, use the Change MOPP Level task.

      To set the MOPP level:

      1. Select the simulation object.

      2. Choose Set Disposition MOPP Level. The MOPP Level dialog box opens.

      3. Select an option from the list.

      4. Click OK.


      image

    38. Morale

      To set a unit’s morale:

      1. Select the simulation object.

      2. Choose Set Disposition Morale. The Morale dialog box opens.

      3. Adjust the slider or type a value from 0 through 100.

      4. Click OK.

      Setting the State of Simulation Objects — Navigation Preferences

      image

      image

    39. Navigation Preferences

      The Navigation Preferences set data request allows you to specify that when an entity plans its path using navigation data, it should take into account road data, if it is avail- able.

      When an entity is set to Prefer Roads, the entity gives preference to all segments along the preferred graph over those on the non-preferred movement graph. This is typically used to have vehicles prefer movement along roads, rather than cutting across open terrain, even if the distance along roads is longer.

      If the movement mode is Avoid Roads, entities try not to move along roads. If they must cross a road, they take the shortest path across the road.

      You can configure an entity to start up with a navigation preference or to ignore roads by editing the initial-road-preference parameter in the navigation-preference controller in the movement system definition file for this entity type.

      To set navigation preferences:

      1. Select the entity.

      2. Choose Set Action Navigation Preferences. The Navigation Preferences dialog box opens.

      3. To have the entity take road data into account, select Prefer Roads or Avoid Roads from the Navigation Preferences list. To have an entity plan its path as if there were no road data, select Ignore Roads.

      4. Click OK.


    40. Notify Level

      You can set the notification level for entity console messages without opening the Infor- mation dialog box. You can also set the notification level for combat engineering objects in aggregate-level scenarios.

      To set the notification level:

      1. Choose Set Other Notify Level. The Notify Level dialog box opens.

      2. Select a notification level in the list.

      3. Click OK.


      image

    41. Ordered Speed

      Setting the State of Simulation Objects — Percent Complete

      The ordered speed is the speed at which you want a simulation object to move. It may not move at that actual speed due to soil type, slope, and so on. In aggregate-level scenarios, speed may be affected by modifiers. If you set the speed while a simulation object is moving, it accelerates or decelerates from the current speed to the new ordered speed, if it can.

      A negative value causes the entity to go backwards if it supports backwards movement.


      image

      i

      i

    42. Percent Complete

      Percent Complete lets you set the degree of completion for combat engineering objects in aggregate-level scenarios.

      To set the percent complete:

      1. Select a combat engineering object.

      2. Choose Set Disposition Percent Complete. The Percent Complete dialog box opens.

      3. Adjust the slider or type a value in the box.

      4. Click OK.

      Setting the State of Simulation Objects — Posture (Unit)

      image

      image

    43. Posture (Unit)

      You can set the posture of a simulation object in an aggregate-level scenario. The posture changes instantly. To change posture over time, use the Change Posture task.

      To set a simulation object’s posture in an aggregate-level scenario:

      1. Select the simulation object.

      2. Choose Set Disposition Posture. The Posture dialog box opens.

      3. Select an option from the list.

      4. Click OK.


      image

      image

    44. Posture (Human)

      Setting the State of Simulation Objects — Posture (Human)

      A human entity (civilian or dismounted infantry) has a posture that determines its posi- tion when it is not moving and its type of movement when it is moving. Table 34-1 lists the position and movement relationships for each posture.

      Table 34-1: Posture relationships


      Posture

      When it is not moving, it is:

      When it is moving, it is:

      standing

      standing

      walking or running

      kneeling

      kneeling

      crawling

      prone

      prone

      crawling

      running

      standing

      walking or running

      walking

      standing

      walking or running

      crawling

      prone

      crawling

      parachuting

      standing

      walking or running

      jumping

      standing

      walking or running

      sitting

      standing

      walking

      squatting

      prone

      crawling

      crouching

      prone

      crawling

      wading

      standing

      walking or running


      image

      i

      i

      • For those postures listed as “walking or running”, VR-Forces sets the movement posture based on the entity’s speed.

      • If an entity does not support a particular posture, it is set to the closest supported posture.

      • Setting posture in the Lifeform State field of the Appearance dialog box has the same effect as setting the posture using the Posture set data request.

      • Some embarkation slots specify the posture of occupants.


        image


        To set a lifeform’s posture:

        1. Select the lifeform.

        2. Choose Set Appearance Posture. The Posture dialog box opens.

        3. Select a posture from the list.

        4. Click OK.

        Setting the State of Simulation Objects — Preferred Targets

        image

        image

    45. Preferred Targets

      Units can target up to three simulation objects. By default, they target the three simula- tion objects that are most vulnerable to attack. If you want a simulation object to target specific simulation objects that it might not choose automatically, the Preferred Targets set data request lets you specify them as preferred targets.

      To specify preferred targets:

      1. Select a unit.

      2. Choose Set Engagement Preferred Targets. The Preferred Targets dialog box opens.

      3. Select up to three simulation objects.

      4. Click OK.


      image

    46. Radar Mode

      Setting the State of Simulation Objects — Reorganize

      The Radar Mode set data request lets you change the type of beam that an entity emitter publishes. By default, each fixed-wing aircraft has one emitter that has two beam types, search and track.

      Figure 34-2 illustrates the difference in appearance between the beams for the two radar modes, in the 2D view. (The beams are not displayed unless you set emitters to be on.)



      image image

      Search Track


      Figure 34-2. Radar mode beams

      For more information about emitter beams, please see “Emitter,” on page 34-18 and “Configuring Emitters,” on page 74-2.

      To set an entity’s radar mode:

      1. Select the entity whose radar mode you want to set.

      2. Choose Set Sensors Radar Mode. The Radar Mode dialog box opens.

      3. If the entity has more than one emitter, select the emitter ID you want to set in the Emitter ID list.

      4. Select the mode in the Mode list.


    47. Reorganize

      If automatic reorganization is not enabled, you can reorganize a unit by issuing the Reorganize set data request.

      To reorganize a unit:

      1. Select the unit that you want to reorganize.

      2. Choose Set Unit Reorganize.

      The change takes place immediately. For more information about reorganization, please see “Reorganizing Units,” on page 22-4.

      Setting the State of Simulation Objects — Resources

      image

    48. Resources

      You can specify the value to assign to a resource. In entity-level scenarios, the resources provided with VR-Forces that you can set are fuel and ammunition. The object param- eter database lists the ammunition types available for each type of simulation object. In aggregate-level scenarios a simulation object might not have any resources, depending on how it is configured in the Simulation Object Editor.

      To specify a resource value:

      1. Select the simulation object.

      2. Choose Set Disposition Resources. The Resources dialog box opens.

      3. Select a resource from the Resource list. The dialog box displays the maximum amount of the resource allowed, as configured in the object parameter database.

      4. Specify a value for the resource.

      5. Click OK.


      image

    49. Resources Pacing/Tracking

      Resources Pacing/Tracking lets you specify that a resource type be marked as pacing, tracking, or neither. Pacing indicates that the status of this item is critical to the mission. Tracking indicates that the commander is interested in the status of this item. These designations do not affect the simulation. They are reported for use by external systems.

      To set pacing and tracking for a resource:

      1. Select the simulation object.

      2. Choose Set Disposition Resource Pacing/Tracking. The Resources Pacing/Tracking dialog box opens.

      3. Select Resources.

      4. Click OK.


      image

    50. Restore

      Setting the State of Simulation Objects — Resupply Mode

      Restoring a simulation object returns its resources to the values specified in the object parameter database. If the simulation object is destroyed, it returns it to life.


      image

      i

      i

      When you restore an entity-level unit that is in the aggregated state (using Restore), the original configuration of the unit is recreated. If you restore a unit that is in the disaggregated state, then only those subordinates still present in the simulation are restored. Any destroyed subordinates that were previously removed from the simulation as result of a disaggregate--> aggregate-->disaggregate transition are not restored. To fully recover all subordinates, restore the unit while in the aggregated state.


      image


      To restore a simulation object:

      1. Select the simulation object.

      2. Choose Set Disposition Restore.


      image

    51. Resupply Mode

      Resupply Mode specifies one of the following resupply modes for simulation objects in an aggregate-level scenario:

      • None. The simulation object does not resupply itself.

      • From Supply Units. When a resupply unit is in range, the unit gets supplies from it.

      • From Self-Continuous. The unit resupplies itself continuously based on its resupply rate parameters. For details, please see “Logistics,” on page 23-13.

      • From Self-Periodic. The unit periodically resets all of its supplies, except health, to the base level. This level is reduced by health losses.

        To specify the resupply mode:

        1. Select the unit.

        2. Choose Set Logistics Set Resupply Mode. The Resupply Mode dialog box opens.

        3. Select a resupply mode from the Resupply Mode list.

        4. If you select From Self-Periodic, specify the resupply period in the Periodic Resupply Period boxes.

        5. Click OK.

        Setting the State of Simulation Objects — Rules of Engagement

        image

    52. Rules of Engagement

Rules of engagement specify the conditions under which a simulation object will fire at the enemy.


image

i

i

The rules of engagement for a fixed-wing entity are in effect whether it is on the ground or in the air. If you do not want fixed-wing entities to fire missiles while they are on the ground, you must change the rules of engagement.


image


To specify the rules of engagement for a simulation object:

  1. Select the simulation object.

  2. Choose Set Engagement Rules of Engagement, or click the Rules of Engage- ment button image) on the Sets Toolbar. The Rules of Engagement dialog box opens.

  3. In the Rules of Engagement list, select the rule you want to apply.

  4. Click OK.


      1. How Fire-When-Fired-Upon Works

        A simulation object considers itself under fire if either of the following is true:

There is no attempt to return fire specifically at the attacking entity. If a simulation object thinks that it is under fire, it will fire at any enemies that it can target.


image

i

i

The underFireTime and underFireDistance parameters are part of the under-fire- determination-sensor component in a simulation object’s platform (OPE) file.


image

Setting the State of Simulation Objects — Sector of Responsibility

image

    1. Sector of Responsibility

      A simulation object's sector of responsibility is used with detection tables to determine the priority of targets. Normally, the priority of targets that are outside a simulation object's sector of responsibility is lower than the priority of targets in its sector of responsibility. For information about the target detection tables, please see “Detection Tables,” on page 71-14.

      You must specify a sector center and a sector size. Sector center is the center of the area you wish to designate, and sector size is the size of the area, both in degrees. Degrees are measured as 0 to the front (based on the heading), increasing clockwise. If the Turret Scan Controller is mounted on an entity with an articulating turret, then the turret scans the sector of responsibility specified. Sector center is the midpoint of the area.

      Figure 34-3 illustrates these parameters. The sector size is approximately 140 degrees, a bit less than half the circle. The sector center is at 0 degrees.


      image

      i The default sector of responsibility is 90 degrees, centered at zero degrees.

      image


      image

      area center


      sector size


      entity



      Figure 34-3. Sector of responsibility parameters

      To set a simulation object’s sector of responsibility:

      1. Select the simulation object.

      2. Choose Set Engagement Sector of Responsibility. The Sector of Responsibility dialog box opens.

      3. In the Size text box, set the size of the area to be scanned, in degrees.

      4. In the Center text box, set the center of the scan area, in degrees.

      5. Click OK.

        Setting the State of Simulation Objects — Sensor Aim

        image

        image

    2. Sensor Aim

      The Sensor Aim set data request specifies where a gimbaled sensor should look.

      You can also aim a gimbaled sensor from the Sensor View control panel. For details, please see “Controlling the Sensor View,” on page 51-10.

      To aim a sensor:

      1. Select an entity that has a gimbaled visual sensor.

      2. Choose Set Sensors Sensor Aim. The Sensor Aim dialog box opens.

      3. Choose an aiming option and provide the required input, as follows:

        • Aim at Point. Click on the terrain or type in coordinates. By default, the altitude is the altitude of the entity.

        • Aim at Object. Select the simulation object to aim at.

        • Aim at Angle. Specify the Azimuth (the horizontal angle relative to the sensing entity) and elevation (the vertical angle that the sensor aims at).

        • Scan. By default, the sensor scans back and forth within a 180 degree range. You can change the elevation and azimuth angles in the gimbaled sensor system defi- nition file.

      4. Click OK.


    3. Sensor Enabled

      The Sensor Enabled set data request lets you enable and disabled individual sensors on a simulation object.

      To enable or disable a sensor:

      1. Select the simulation object.

      2. Choose Set Sensors Sensor Enabled. The Sensor Enabled dialog box opens.

      3. In the Sensor list, select the sensor you want to enable or disable, or select All.

      4. In the Enabled list, select Yes or No.

      5. Click OK.


        image

        image

    4. Sensor Zoom

      Setting the State of Simulation Objects — Sensor Zoom

      The Sensor Zoom set data request lets you change the field of view of a gimbaled visual sensor, essentially zooming in on the aim point.

      You can also zoom a gimbaled sensor from the Sensor View control panel. For details, please see “Controlling the Sensor View,” on page 51-10.

      To zoom a visual sensor:

      1. Select the entity whose sensor you want to zoom.

      2. Choose Set Sensors Sensor Zoom. The Sensor Zoom dialog box opens.

      3. If the entity has more than one sensor, in the Sensor list, select the sensor you want to zoom.

      4. Type the zoom level you want or drag the slider.

      5. Click OK.

        Setting the State of Simulation Objects — Sonar Depth

        image

        image

    5. Sonar Depth

      The Sonar Depth set data request lets you set the depth at which an entity’s sonar oper- ates. This allows you to simulate a helicopter dipping a sonar sensor into the water or a vessel dipping a sensor to a lower depth. Since sonar only works when the sensor is in the water, setting the sonar depth is the only way for helicopter-born sonar to work.

      The sonar stays at this depth regardless of the altitude or depth of the entity. If you set the depth to be the depth of the entity with the Use Entity Depth option, it has the effect of retracting the sonar. If you set the sonar to the depth of the entity and the entity changes depth, the sonar stays at the assigned depth.

      To set sonar depth:

      1. Select the entity.

      2. Choose Set Sensors Sonar Depth. The Sonar Depth dialog box opens.

      3. Specify the depth.

      4. Optionally, select Use Entity Depth to set a dipped sonar to the depth of the entity.

      5. Click OK.


        image

    6. Spot Reports

      Setting the State of Simulation Objects — Spot Reports

      You can set spot reports on or off for all simulation objects (global setting) from the Spot Report Options page of the Application Settings dialog box. You can also set them for individual simulation objects. When you set spot reports on, it means that the simu- lation object sends them. Visualization of spot reports is enabled or disabled for the GUI as a whole on the Spot Report Options page. For more information about spot reports, including setting them globally, please see “Displaying Simulation Objects Based on Spot Reports,” on page 9-2.


      image

      i

      i

      You cannot set a unit in an entity-level scenario to send spot reports; you can only set spot reports for individual simulation objects. However, you can select multiple individual simulation objects and set spot reports for all of them at the same time.


      image


      To set spot reports on or off for a simulation object:

      1. Select the simulation object.

      2. Choose Set Sensors Spot Reports. The Spot Reports dialog box opens. If you are turning spot reports off, skip to step 5.

      3. Select one of the following options:

        • Only to Front End. Do not send spot reports to other back-ends. This option can improve performance.

        • Broadcast. Send spot reports to all simulation objects.

        • Send to Specific Entities. Sends to specific simulation objects.

      4. If you selected Send to Specific Entities, the simulation object list is enabled. Select the simulation objects to which you want this simulation object to send sport reports.

      5. Select an option from the Spot Reports Enabled list. If you choose On or Off, the setting persists regardless of the global spot report setting. If you want the simula- tion object to use the global spot report setting, choose Use Global Setting.

      6. Click OK.

        Setting the State of Simulation Objects — Superior

        image

    7. Superior

      The Superior set data request lets you add a simulation object (individual or unit) to a unit or move a simulation object from a unit to the force level. The superior unit must already exist. For entity-level scenarios, the superior unit must be disaggregated. For aggregate-level scenarios, the superior must be a higher echelon unit.

      To specify a simulation object’s superior:

      1. Select the simulation object.

      2. Choose Set Other Superior. The Superior dialog box opens.

      3. Optionally, filter the list.

      4. Select the unit that you want to be this simulation object’s superior. If you want to move the simulation object out of a unit to the force level, select the Set Force As Superior check box.

      5. Click OK.


        image

    8. Supplying

      The Supplying set data request sets a supply unit to stop providing supplies or to start providing supplies.

      To stop or start a supply unit providing supplies:

      1. Choose Set Logistics Supplying. The Supplying dialog box opens.

      2. Select Stop or Start.

      3. Click OK.


        image

    9. Surrendered

      The Surrendered set data request only applies to lifeforms. When a lifeform is in the surrendered state, it does not fire at other simulation objects and other simulation objects do not fire at it.

      To set an entity to be surrendered:

      1. Select the entity.

      2. Choose Set Disposition Surrendered. The Surrendered dialog box opens.

      3. Select an option from the list.

      4. Click OK.


        image

        image

    10. Synchronize Laser Code

      Setting the State of Simulation Objects — Target

      The Synchronize Laser Code set data request lets an entity with laser-guided weapons easily synchronize its laser code with the laser code of the lasing entity. The alternative to this command would be to use the Laser Code set data request to set the code for the lasing entity and the firing entity.

      To synchronize laser codes:

      1. Select the entity that has a laser-guide weapon.

      2. Choose Set Laser Designator Synchronize Laser Code. The Synchronize Laser Code dialog box opens.

      3. Select the lasing entity that you want this entity to synchronize with.

      4. Click OK. The laser code for the selected entity is changed to match that of the lasing entity.


        image

    11. Target

      You can command an entity to specifically target another entity. For this set data request to be effective, the target must be visible to the targeting entity. When you set a target, you override the priorities set by the target selection controller. If the specified target is in the list of candidate targets, it gets the highest priority as a target. However, if the specified target is not visible as a target to the targeting entity, the entity fires at the other available targets. It does not keep looking for the specified target.

      To set an entity’s target:

      1. Select the entity.

      2. Choose Set Engagement Target. The Target dialog box opens.

      3. Optionally, filter the entity selection list.

      4. In the Target list, or on the terrain, select the entity to target.

      5. Click OK.

        Setting the State of Simulation Objects — Tasked by Superior

        image

    12. Tasked by Superior

      You can order a simulation object that is part of a unit, and which is executing its own plan or is conducting an independent task, to stop executing those tasks and take commands from its unit. When you order a simulation object to be tasked by its supe- rior, it stops conducting independent tasks and waits for the next order from the unit. (It does not execute the unit’s current task, if any.) For more information about being tasked by superior, please see “Independently Tasking Unit Members,” on page 26-12.

      To order a simulation object to be tasked by its superior:

      1. Select the simulation object.

      2. Choose Set Other Tasked by Superior.


        image

    13. Tracer Use

      You can specify use of tracer rounds for entities that have weapons that support them. To see tracers, you must enable them for the observer you are using. They are not supported in 2D observer modes.

      To enable or disable user of tracers:

      1. Select the entity for which you want to enable or disable use of tracers.

      2. Choose Set Engagement Tracer Use. The Tracer Use dialog box opens.

      3. Choose an option from the User Tracers list.

      4. Click OK.


        image

    14. Unit State

      The Unit State request lets you change an entity-level unit from the aggregated state to the disaggregated state and vice versa.

      To set a unit’s aggregation state:

      1. Select the unit.

      2. Choose Set Unit Unit State. The Unit State dialog box opens.

      3. Select the desired state from the list.

      4. Click OK.

        Setting the State of Simulation Objects — Weapons Pacing/Tracking

        image

        image

    15. Weapons Pacing/Tracking

      Weapons Pacing/Tracking lets you specify that a weapon be marked as pacing, tracking, or neither. Pacing indicates that the status of this item is critical to the mission.

      Tracking indicates that the commander is interested in the status of this item. These designations do not affect the simulation. They are reported for use by external systems.

      To set pacing or tracking for a unit’s weapons:

      1. Select the simulation object.

      2. Choose Set Disposition Weapons Pacing/Tracking. The Weapons Pacing/Tracking dialog box opens.

      3. Select the check box for each weapon for which you want to specify pacing or tracking.

      4. For each selected weapon type, select an option from the list.

      5. Click OK.

Setting the State of Simulation Objects — Weapons Pacing/Tracking

image


This section describes how to write plans.


VI.1. Introduction to Plans

VR-Forces has two kinds of plans, global plans and individual plans. Both kinds of plans can assign tasks and set data requests to a simulation object. Plans can also contain commands that create or delete simulation objects and tactical graphics. The commands in a plan can be conditional, that is, they will be executed only if a condi- tion is satisfied. When you open a scenario, it is in pause mode (unless you start it with the -l command line option). When you start the simulation, the plans start executing.

Global plans are created and executed independently of any particular simulation object. Commands sent to simulation objects from a global plan affect them as if they received an independent task through the Task menu — they interrupt the current task, if any, and cause the simulation object to abandon its plan, if it has one.

An individual plan is a set of statements that order a particular simulation object to complete a sequence of tasks, change its state, or both. The simulation object carries out the tasks in order unless it is interrupted by an independent task or global command.

A simulation object owns its individual plan. Changing its name, echelon relationship, or force does not change its plan.

If a simulation object does not have a plan, it does not mean that it has nothing to do. A simulation object may be assigned tasks by its superior in the force hierarchy. It can also be assigned tasks interactively from the front-end. If you want a simulation object to take planned actions independently of those assigned by its superior, you need to add statements to its plan.



VR-Forces Users Guide


Section VI - Plans


VI-1

Plans — Introduction to Plans

image


You can view a simulation object’s plan at any time in the Plan window. The task that a simulation object is currently executing is highlighted. A simple plan might look like the following:

Move-To Waypoint:"red point" Wait-Duration Seconds-ToWait:900 Move-To Waypoint:"white point"

Set Engagement-Rules="Fire-at-will"


image

!

!

You can edit plans while a simulation is running. However, when you change a plan during a simulation, the simulation object starts executing the plan from the beginning, which may cause its activities to be out of synchronization with the other simulation objects in the simulation.


image


Section VI - Plans

VI-2 VT MAK


This chapter describes plans and plan concepts.

Introduction to Individual Plans and Global Plans 35-2

Conditional Statements 35-4

The If Statement 35-6

Triggers 35-7

While Statements 35-9

Wait Until Statements 35-9

Conditional Tests 35-10

Plan Variables 35-15

Viewing Plans 35-16

Considerations for Creating Plans 35-17

Considerations for Using Triggers 35-17

Using Concurrent Tasks in Plans 35-18

Moving In Formation 35-18

Using the Tasked-By-Superior Request in a Plan 35-18

Following Simulation Objects 35-18

Planning Tasks for Aircraft 35-19

Using Non-VR-Forces Simulation Objects in Plans 35-19

Plan Concepts — Introduction to Individual Plans and Global Plans

image

    1. Introduction to Individual Plans and Global Plans

      A plan contains one or more statements that get executed by VR-Forces without human intervention. You build these statements in dialog boxes. VR-Forces writes the state- ment to the plan, so you do not have to worry about syntax errors in your statements when you first create them. However, you must understand the meaning of individual commands and parameters and the implications of how you order them, to make sure that a plan does what you want it to do.

      VR-Forces supports two types of plans – individual plans and global plans. They have the following characteristics:

      • Individual plans apply to a specific simulation object. They contain tasks and set data requests that are specific to the simulation object and which get executed sequentially. The sequence of task execution can be interrupted by receipt of a task from an external actor (a global plan command or independent task). The task sequence can also be interrupted if a trigger (a form of conditional statement) or a reactive task is activated.


        image

        !

        !

        Individual plans can include global commands (which are described later in this section). However, you must be careful not to use global commands, tasks, or sets for a simulation object in its own plan when you really want simulation object-specific tasks or sets. Sending a simulation object a global command, even from within its own plan, terminates its plan.


        image


      • Global plans are independent of any simulation object. The statements in a global plan affect the scenario as a whole (create and delete object commands) or a specific simulation object (task and set commands). Tasks sent to a simulation object from a global plan have the same effect on the simulation object as independent tasks assigned by a human player. They interrupt any task that the simulation object is engaged in and terminate its plan. Furthermore, if a global plan has a series of tasks for the same simulation object, they get sent in order without regard to completion of the previous task (as if you issued a series of commands from the Task menu, one immediately after another). In such a case, only the last command sent is likely to be completed.

        Figure 35-1 shows a global plan and an individual plan. Note that the individual plan window (on the right) is tied to a particular simulation object (shown in the title bar).

        Plan Concepts — Introduction to Individual Plans and Global Plans

        image


        image image

        Figure 35-1. Global plan and individual plan


    2. Conditional Statements

      Many of the statements used in plans set a parameter or direct a simulation object to perform a specific task unconditionally. However, the plan language also includes conditional statements. A conditional statement specifies a condition and a block of plan statements that get executed if the condition is true. VR-Forces supports the following conditional statements:

Conditional statements can test for True and False, and can include the logical opera- tors AND, OR, and NOT.

For details, please see “Conditional Tests,” on page 35-10.


      1. The If Statement

        An If statement tests a condition. It only tests the condition once.


        image

        i

        i

        Do not use an If statement to test for receipt of a message or some other circumstance that does not represent a simulation object’s state. VR-Forces does not keep a record of events and such a test will almost always evaluate to false. Use a trigger to test for conditions that do not evaluate simulation object state.


        image


        An If block consists of:

        • The word If.

        • A condition to be evaluated.

        • A block of statements.

        • An else statement.

        • Optionally, statements for the else condition.

        • An endif statement.

          If the condition is true at the moment the If statement is evaluated, control passes to the first statement of the If block. If the condition is false, control passes to the first statement in the else block, if you have one, or to the first statement after the complete If block if you do not have an else block. You can nest If statements within If statements. The syntax is as follows:

          If (condition) then

          zero_one_or_more_statements

          else

          zero_one_or_more_statements

          endif

          When VR-Forces reaches the end of the block of If or else statements, control passes to the first statement after the If statement.

          The Add Conditional Expression dialog box ensures that you have the correct syntax. It does not ensure that your If block makes logical sense.


      2. Triggers

        A trigger consists of a condition and a block of statements that are executed when the condition becomes true.

        When you create a trigger, it is not automatically added to the plan’s execution sequence. You must register a trigger before VR-Forces will test it. (If you have a programming background, it may be helpful to think of triggers as functions or subrou- tines that you write separately and then call from elsewhere in a plan. Extending the analogy, a trigger is always local to its plan.)

        When you register a trigger, VR-Forces checks the condition. If the condition is true, control passes to the first statement in the trigger. If the condition is false, VR-Forces continues to the next statement in the plan. It continues to check the trigger condition periodically. If at any point, the condition evaluates as true, control passes to the block of statements associated with the trigger.

        When you create a trigger, you can specify that it interrupt the current task or that it suspend and resume the current task.

        If you specify that a trigger interrupt the current task, task execution proceeds as follows:

      3. While Statements

        A While statement consists of:

        • The word While.

        • A condition to be evaluated.

        • A block of statements.

        • An endWhile statement.

          If the condition is true at the moment the While statement is reached, control passes to the first statement of the While block. If the condition is false, control passes to the first statement after the complete While block. You can nest While statements within other conditional blocks.

          When VR-Forces reaches the end of the While block, it evaluates the condition again. If the condition is still true, VR-Forces executes the statements again. If it is false, control passes to the first statement after the While block.


          image

          i

          i

          • VR-Forces re-evaluates a While condition only after it has executed all of the statements in the block. If the condition becomes false while VR- Forces is executing statements in the block, VR-Forces continues to execute all statements because it does not re-evaluate the condition until it completes the While block.

          • If you put a continuous task such as Wait or Patrol Between in a While block, it is possible that the condition will never be re-evaluated, because these tasks never finish.


            image


      4. Wait Until Statements

        A Wait Until statement consists of:

        • The words Wait Until.

        • A condition to be evaluated.

          If the condition is true at the moment the Wait Until statement is reached, the simulation object continues to the next task in the plan. If the condition is false, the simulation object waits in place. VR-Forces continues to check the condition periodi- cally until the condition becomes true or the simulation object is tasked by some other form of input, such as a trigger or independent task.

          If a Wait Until state is interrupted by a trigger and the trigger’s Interrupt Current Task check box is not selected, the plan returns to the Wait Until state after the trigger’s tasks are completed. If the trigger’s Interrupt Current Task check box is selected, the plan moves to the statement after the Wait Until.

          If the condition becomes true, control passes to the next statement in the plan.


      5. Conditional Tests

        This section describes each of the conditions that VR-Forces can test. When you set up conditions, keep in mind the following:

        • If there is no simulation object with the specified name, the result is always false.

        • If the specified simulation object is destroyed, the condition might never be satis- fied. Your plan should take this possibility into account.


Altitude

Altitude returns true if the simulation object (or member of a unit) is at a higher or lower altitude than the one specified.


Detect Entity

The Detect Entity condition tests to see if this simulation object has detected another simulation object at a particular identification level. The identification levels are Detected, Classified, Identified, and Full Knowledge. Identification levels are deter- mined by the detection probability configuration files, based on the distance between the detecting simulation object and the target and for how long the simulation object has been detected. For details about the detection probability files, please see “Detec- tion Tables,” on page 71-14.


image

i This condition is not supported in global plans.

image

image Engineering Object Breached

The Engineering Object Breached condition returns true if the specified engineering object has been breached. (Aggregate-level scenarios only.)


Entity Destroyed

Entity Destroyed returns true if the specified simulation object is destroyed.


image

i

i

The definition of destruction for a unit is implementation specific. For the entity-level models provided with VR-Forces, disaggregated units are considered to be destroyed when all members of the unit are destroyed.

If you have implemented units locally using the VR-Forces Toolkit, they could have a different definition of destroyed.


image


image

Entity Di-Guy Animation Check

The Entity Di-Guy Animation Check condition tests the current DI-Guy animation for a lifeform. This condition may be useful if you are scripting a series of animations. For example, if a particular entity is using a threatening or hostile animation, you might want to have other simulation objects respond a certain way.


image

Entity Di-Guy Appearance Check

The Entity Di-Guy Appearance Check condition tests the current DI-Guy appearance for a lifeform. This condition may be useful if you are scripting a lifeform’s interaction with another lifeform based on ethnicity or how they are dressed.


Entity Embarked

Entity Embarked returns true if the named simulation object is embarked.


Entity Has Target

image

Entity Has Target returns true if the simulation object specified in the condition identi- fies a target. For example, consider the entities in Figure 35-3. The condition in M1A2 1’s plan is true when BMP 1 has a target, not when M1A2 1 targets BMP 1.



image

M1A2 1 BMP 1

Plan for M1A2 1

If(Entity-Has-Target:”BMP 1”) do something

endif

Plan for M1A2 1

If(Entity-Has-Target:”BMP 1”) do something

endif

Figure 35-3. Entity Has Target condition


image

i

i

If a simulation object’s rules of engagement prevent it from firing, this condition does not return true when the simulation object identifies a target.


image


Entity In Area

Entity In Area returns true if the simulation object reports that it is in the named area. You can use the NOT operator, to test whether a simulation object is outside the area.

If a simulation object enters an extruded area, VR-Forces does a 2D check first, to see if it is in the area. Then it checks the simulation object’s altitude to see if it is within the area’s volume.

If you have a plan in which you are testing for entities in an area and destroying them as they enter it, the Exclude Destroyed Simulation Objects option lets you reregister a trigger and only test for entities that have not been destroyed.


Entity Left of Line

Entity Left of Line returns true if the simulation object reports that it is to the left of the specified phase line.

A simulation object is considered to be to the left of a phase line if it is on the left side of an infinite extension of the phase line as viewed from a point on the line facing in the direction of the line. For a description of phase line direction, please see “Phase Lines,” on page 37-4.


Entity Under Fire

Entity Under Fire returns true if the simulation object is under fire.


image

Lifeform Surrendered

The Lifeform Surrendered condition tests to see if a lifeform entity has surrendered (using the Surrendered set data request).


Missile Approach Warning

The Missile Approach Warning condition returns true if a hostile missile is within the specified distance of this simulation object. This condition is not available in global plans.


Random

You can use the Random condition to randomly decide a simulation object's behavior at run time.

Percentage – A floating point probability percentage value between 0% (zero) and 100%. Random returns true if a random number between zero and 100 is less than or equal to the specified value.

If you use the Random condition, consider the following issues:

If (Random Probability:33.33%) then Move-Along Route:"1"

Else

If (Random Probability:50%) then Move-Along Route:"2"

Else

Move-Along Route:"3" Endif

Endif


Resource

The Resource condition tests the amount of a specified resource for this simulation object using comparison operators. This condition is not available in global plans.


Receive Text Message

The Receive Text Message condition tests to see if this simulation object has received a text message (sent by the Send Text Message task) that contains the text specified in the Receive Text Message dialog box. This condition is not available in global plans.


Scenario Event

The Scenario Event condition returns true if the specified scenario event is in process or has completed.


Simulation Time

The Sim Time condition returns true if the elapsed simulation time is greater than (Sim Time >) or less than (Sim Time <) the time specified in the statement. Sim Time is the elapsed simulation time in days, hours, minutes, and seconds.


Simulation Date/Time

The Simulation Date/Time condition returns true if the simulation date and time matches the specified value.


Tactical Graphic Active

The Tactical Graphic Active condition returns true if a published tactical graphic is in the active state. For details about setting a tactical graphic’s state, please see “Active and Inactive Tactical Graphics,” on page 39-19 and “Activation,” on page 40-3.


Boolean Operators

You can use the following boolean operators in conditional expressions:


image

    1. Plan Variables

      Plan Concepts — Plan Variables

      Many tasks require you to specify a simulation object to act on, such as Fire on Target. Conditional tests, such as Entity Destroyed, require you to identify a simulation object to evaluate. However, you will not always know the name of the simulation object that you need to specify. Variables let you specify a simulation object without knowing its name. Plans can reference two variables:

      • Simulation Object. The Simulation Object variable references a simulation object that has been identified by a conditional test, such as Entity in Area or Entity Left of Line. For example, suppose that if an opposing force entity enters an area you want to fire at it. You can create a trigger using an Entity in Area condition. Then in the body of the trigger, you can insert a Fire at Target task that specifies the Simulation Object variable rather than the name of a specific entity.

        In an AND condition, the variable is set to the last condition satisfied. In an OR condition, the variable is set to the first condition satisfied.

      • Created Object. The Created Object variable references the most recently created object. For example suppose you create an object from a plan and do not give it a name. You can issue it a plan or refer to it using the Create Object variable. This variable refers to the most recently created object.

        Plan variables are specific to each simulation object plan. A variable value in one plan does not affect the variable value in a different plan. Therefore, if you want to use the Created Object variable, you must create the object in the plan in which you want to use it. You could not, for example, create an object in a global plan and then reference it using the Created Object variable from a simulation object’s plan.

        Once a variable has a value, you can use that variable in a plan as many times as you want to. However, you will need to keep track of plan logic that might change the value as the simulation object progresses through the plan.

        For details about how to use variables in plans, please see “Using Plan Variables,” on page 36-25.

        Plan Concepts — Viewing Plans

        image

    2. Viewing Plans

      You can view a simulation object’s plan and observe its progress through the plan. State- ments are numbered to show the order in which they will execute unless interrupted by a trigger, independent task, or other external input. If a plan is executing the statements in a conditional block, VR-Forces draws a box around the block and the numbering is shown for the statements in the block.

      If the Plan window is collapsed (that is, the Trigger pane is not visible) and control passes to a trigger, the window automatically expands to show the tasks in the trigger that is being executed.

      The task that a simulation object is executing is highlighted in the Plan window. When the simulation object completes its plan, a message is displayed in the status area at the bottom of the Plan window.

      You can view the plans for as many simulation objects at a time as you want. In addi- tion to viewing plan status in the Plan window, you can view the current task on the Task Status page of the Information dialog box. The Last Selected Object panel also lists the currently executing task.

      To view a simulation object’s plan:

      1. Select the simulation object whose plan you want to view.

      2. Choose Objects Plan, or press p. The Plan window opens.


    3. Considerations for Creating Plans

This section has tips for constructing plans including how to avoid problems that are hard to debug and how statements affect each other, with implications for how to orga- nize the statements in a plan.


      1. Considerations for Using Triggers

        Triggers are a versatile part of plans and you should have a good understanding of their intricacies before you use them.


        Deciding Where to Put Triggers

        VR-Forces does not evaluate a trigger condition until it registers the trigger. If you want to ensure that a trigger always gets evaluated by VR-Forces, register it at the beginning of a plan before any non-trigger statements. If you register a trigger later in a plan, it is possible that it will never be evaluated. This could occur if a plan is abandoned. Of course, you might decide that you do not want a trigger to be evaluated unless a set of preceding tasks have been completed. In that case, placing it later in the plan may be exactly what you want to do.

        You can also register a trigger inside a conditional block so that it gets registered only if a particular condition is true at a particular time.

        For example, if you always want entity 1 to respond to entry of hostile forces into an area, put a trigger at the beginning of the plan. If you want entity 1 to respond to a hostile simulation object in an area only after the simulation has progressed for 15 minutes, nest the trigger inside another trigger that fires when Sim Time > 15 minutes.


        Using Triggers That Do Not Have Mutually Exclusive Tasks

        A trigger does not have to have any task statements in its statement block. It could just have Set statements. Or, it could have sets and concurrent tasks. If a trigger block just has Set statements, it does not interrupt the task that the simulation object is executing when the trigger gets executed. The Set statements get executed while the simulation object is performing its task. This has the same effect as if you manually set the simula- tion object’s state while it was performing a task.

        Using a trigger that just has Set statements can be useful if you want to change a simu- lation object’s state under certain conditions, but do not know in advance when those conditions might exist.


      2. Using Concurrent Tasks in Plans

        If you are assigning tasks to simulation objects manually, you can give a simulation object a concurrent task while it is executing some other task. You cannot do this directly in a plan, because you cannot assign two tasks at the same time. A plan always waits for its current task to complete before it starts the next task, even if the next task does not conflict with the current one. If you want to assign a concurrent task in a plan, you must use a trigger. If a trigger that just has a concurrent task fires, the simulation object will execute the concurrent task and continue with its existing task. If the trigger has other tasks, the behavior will be as expected for triggers.

        For more information about concurrent tasks, please see “Concurrent Task Execution,” on page 26-5.

        As an alternative to using plan triggers to automatically assign concurrent tasks, you can create reactive tasks. For information about reactive tasks, please see “Reactive Tasks,” on page 26-12.


      3. Moving In Formation

        If you want a unit to move in a certain formation, you can set the formation (Forma- tion set data request) or you can have the unit move into a formation (Move Into Formation task). The default formation is a column.


      4. Using the Tasked-By-Superior Request in a Plan

        If you put the Tasked-By-Superior request in the body of a plan, it has no real effect. This is because, as soon as it is set, the plan goes to the next task and overrides the supe- rior. The only way that the Tasked-By-Superior command gets implemented as part of a plan is if it is the last statement in a plan or the last statement in a trigger that happens to get executed after all the statements in a simulation object’s plan have been executed.


      5. Following Simulation Objects

        If you tell two or more simulation objects to follow another simulation object, do not give them the same offset values. If the followed simulation object stops, one follower will arrive at the specified offset position and stop, while the others will circle the loca- tion because they cannot all occupy the same space.


      6. Planning Tasks for Aircraft

        When you plan tasks for aircraft, the most important thing to remember is to pay atten- tion to the terrain. Fixed-wing aircraft do not have terrain following capabilities.

        Rotary-wing aircraft have some terrain-following capacity, but it has some limitations. So if you assign aircraft an altitude that is lower than the terrain at some point along a route or the path they must follow to reach a waypoint, they will crash into the terrain. View the terrain profile for a route to see if it intersects the terrain.

        You should also bear in mind that a fixed-wing aircraft’s ability to follow a route depends on the speed of the aircraft, its size, and the distance and angle between the points of the route.


      7. Using Non-VR-Forces Simulation Objects in Plans

        You can use a non-VR-Forces simulation object as a parameter in a plan, for example, following a remote simulation object, or testing to see if a remote simulation object is in an area.

        To identify non-VR-Forces entities, VR-Forces uses their marking text. If a non-VR- Forces simulation object does not have marking text, VR-Forces uses its simulation object identifier as its name.

        VR-Forces does not recognize remote units as units, so it cannot check their children. Remote units are ignored by the simulation engine.


        image

        i

        i

        • Referring to remote entities by their marking text may have unpredict- able results if there is more than one remote simulation object with the same marking text.

        • If you include a non-VR-Forces simulation object in a plan you must ensure that the remote simulator uses the same name for the simulation object in future runs.


image


image

36. Writing Plans


This chapter explains how to combine tasks, set data requests, global commands, and conditions into plans.

Writing Plans for Simulation Objects 36-3

Adding a Task or Set Data Request to a Plan 36-4

Adding an If Block to a Plan 36-5

Adding a While Block to a Plan 36-6

Adding a Wait Until Statement to a Plan 36-6

Adding a Trigger to a Plan 36-7

Registering Triggers 36-8

Reregistering Triggers 36-9

Unregistering Triggers 36-9

Cleaning Up Unused Triggers 36-9

Editing a Statement 36-9

Deleting Statements from a Plan 36-10

Printing Plans 36-10

Saving Changes to a Plan 36-10

Building Condition Statements 36-11

Building a Condition Statement that has One Condition 36-11

Building a Complex Condition 36-14

Editing Condition Statements 36-21

Specifying Names or Patterns in Condition Statements 36-22

Using Plan Variables 36-25

Creating Global Plans 36-26

Controlling When Global Plans Run (Quick Launch) 36-28

Opening an Information Dialog Box for a Global Plan 36-28

Adding Commands to a Plan 36-29

image

Writing Plans

Adding Tasks and Sets from the Commands Menu 36-30

Sending Console Messages 36-33

Creating Objects from Within a Plan 36-33

Deleting Objects from Within a Plan 36-33

Issuing a Plan 36-34

Sending View Control Messages 36-35

Writing Plans for Units 36-39

Writing a Plan for Multiple Simulation Objects 36-39

Writing Plans for Remote Entities 36-39

Copying Plans and Plan Statements 36-40

Restarting a Plan 36-41

Abandoning a Plan 36-42

    1. Writing Plans for Simulation Objects

      This section explains how to write individual plans. For conceptual information about plans, please see “Introduction to Plans,” on page 34-1, and the previous sections in this chapter.

      When you write a plan, keep the following considerations in mind:

      • If you edit a plan during a simulation, when you apply the changes, the simulation object whose plan has been changed begins executing it from the beginning. This might mean its activities are no longer synchronized with those of the other simula- tion objects, unless the updated plan only includes statements that you want to execute starting at the current point of the simulation. Therefore, we recommend that you edit plans when you first load a scenario, before you start running the simulation.

      • If you have two or more Plan windows open at the same time, and you open a dialog box, such as Move To, but do not complete the command, you cannot open that same dialog box from another Plan window until you complete the one that is open.

To edit a simulation object’s plan:

  1. Select a simulation object.

  2. Choose Objects Plan, or press p. The Plan window opens. The simulation object’s plan is displayed.


    image

    Figure 36-1. Plan window


    image

    i

    i

    You can also open the Plan window by clicking the Plan button image) on the Last Selected Object Panel.


    image


  3. Add new statements, edit statements, or delete statements as described in the following sections.


      1. Adding a Task or Set Data Request to a Plan

        When you add statements to a plan, you add them after the currently selected state- ment.

        To add a task to a plan:

        1. Open the Plan window for a simulation object.

        2. In the Plan window, select the statement immediately above where you want to insert a new statement. If the plan does not have any statements yet, the plan root – Plan is already selected.

        3. Choose Task category Task, where category is one of the categories on the Task menu and Task is a task listed for the selected category. A dialog box appropriate to the task opens. The procedures for filling out each type of task dialog box are described in Chapter 26, Assigning Tasks through Chapter 31, Tasks for Aggregate- Level Scenarios.

        4. Complete the required parameter information.

        5. Click OK in the task dialog box to add the statement. You can click Cancel at any time to exit a task dialog box.

          To add a set data request to a plan, follow the same procedure as for adding a task, except choose Set category Set Data Request.

          The procedures for filling out Set statement dialog boxes are in Chapter 34, Setting the State of Simulation Objects.


          image

          i

          i

          Some task and set statements, such as Wait, or Reorganize, do not require you to specify any values. They are added immediately to the plan without any intermediate dialog boxes.


          image


      2. Adding an If Block to a Plan

        To add an If condition to a plan:

        1. Open the Plan window for a simulation object.

        2. In the Plan window, select the statement immediately above where you want to insert the If block. If the plan does not have any statements yet, the plan root – Plan is already selected.

        3. Choose Conditions If. The If/Else Expression dialog box opens (Figure 36-2).


          image

          Figure 36-2. If/Else Expression dialog box

        4. Optionally, in the Description box, type a description to use in the If statement instead of the condition syntax.

        5. Create the conditional expression as described in “Building Condition Statements,” on page 36-11.

        6. Click OK. An If statement block is added to the plan.

        7. Select the first line in the block (the If statement).

        8. Add the tasks, sets, or other commands that you want to be executed if the condi- tion is true.

        9. Optionally, select the else line and add the commands you want to be executed if the condition is false.


      3. Adding a While Block to a Plan

        To add a While block to a plan:

        1. Open the Plan window for a simulation object.

        2. In the Plan window, select the statement immediately above where you want to insert the While block. If the plan does not have any statements yet, the plan root

          Plan is already selected.

        3. Choose Conditions While. The While Expression dialog box opens. (It is iden- tical to the If/Else Expression dialog box (Figure 36-2).)

        4. Optionally, in the Description box, type a description to use in the While state- ment instead of the condition syntax.

        5. Create the conditional expression as described in “Building Condition Statements,” on page 36-11.

        6. Click OK. A While statement block is added to the plan.

        7. Select the first line in the block (the While statement).

        8. Add the tasks, sets, or other commands that you want to be executed if the condi- tion is true.


      4. Adding a Wait Until Statement to a Plan

        To add a Wait Until statement to a plan:

        1. Open the Plan window for a simulation object.

        2. In the Plan window, select the statement immediately above where you want to insert the Wait Until block. If the plan does not have any statements yet, the plan root – Plan is already selected.

        3. Choose Conditions Wait Until. The Wait Until Expression dialog box opens. (It is identical to the If/Else Expression dialog box (Figure 36-2).)

        4. Optionally, in the Description box, type a description to use in the Wait Until

          statement instead of the condition syntax.

        5. Create the conditional expression as described in “Building Condition Statements,” on page 36-11.

        6. Click OK. A Wait Until statement block is added to the plan.


      5. Adding a Trigger to a Plan

        Adding a trigger to a plan is a three-step process. First, you specify the trigger condition. Then you add the commands to be executed to the trigger body. Finally, you register the trigger in the body of the plan.

        To add a Trigger to a plan:

        1. Open the Plan window for a simulation object.

        2. Choose Conditions Add Trigger. The Edit Trigger Condition dialog box opens (Figure 36-3).


          image

          Figure 36-3. Trigger dialog box

        3. Optionally, in the Trigger Name box, type a name for the trigger. If you specify a name, it is displayed in the Register command when you register the trigger. If you do not specify a name, the text of the condition is displayed in the Register command.

        4. Optionally, select the Automatically Reregister Trigger check box to specify that the trigger should be automatically reregistered after it runs.

        5. Optionally, select the Interrupt Current Task check box to specify that the trigger should interrupt the currently running task rather than suspending and resuming it.

        6. Create the conditional expression as described in “Building Condition Statements,” on page 36-11.

        7. Click OK. If the Trigger Body pane is not already visible, the Plan window expands to show the it (Figure 36-4).


          image

          Figure 36-4. Trigger pane

        8. Select the first line in the Trigger pane (Trigger).

        9. Add the tasks, sets, or other commands that you want to be executed when the condition becomes true.

        10. Register the trigger. For details, please see “Registering Triggers,” on page 36-8.


      6. Registering Triggers

        Writing a trigger does not include it in a plan. You must register the trigger.

        To register a trigger:

        1. In the Plan window, select the statement below which you want to register the trigger.

        2. Choose Conditions Register Trigger. The Register Trigger dialog box opens (Figure 36-5).


          image

          Figure 36-5. Register Trigger dialog box

        3. Select the trigger you want to register from the list. (If there are no triggers in the plan, select New.)

        4. Click OK. (If you selected New, the Trigger dialog box opens. Follow the proce- dure for writing a trigger. Then register the trigger.)


      7. Reregistering Triggers

        By default, once the statements in a trigger get executed, the trigger is unregistered and VR-Forces no longer tests the condition. However there may be cases where you want to test for a recurring condition. You could register the trigger again when the trigger block competes. Or, when you create or edit a trigger, you can specify that it automati- cally reregister. For details. please see “Adding a Trigger to a Plan,” on page 36-7.

        As an alternative to using triggers, you can write reactive tasks, which work similarly to triggers or you can write a regular scripted task that is designed to repeatedly test a condition.


      8. Unregistering Triggers

        You can unregister triggers from within a plan. Unregistering a trigger does not remove it from a plan. It causes VR-Forces to stop testing the condition. You might want to unregister a trigger in response to a change in scenario circumstances that makes the actions in the trigger undesirable.

        To unregister a trigger:

        1. Select the plan statement above where you want to add an Unregister Trigger state- ment.

        2. In the Plan window, choose Conditions Unregister Trigger. The Unregister Trigger dialog box opens.

        3. Select the trigger that you want to unregister.

        4. Click OK.


      9. Cleaning Up Unused Triggers

        If you add triggers to a plan and then decide not to use (register) them, you can quickly remove them from the plan. (However, there is no penalty for leaving unused triggers in a plan.)

        To clean up unused triggers, choose Plan Clean Up Unused Triggers.


      10. Editing a Statement

        You can edit simple statements in the Plan window.

        To edit a plan statement:

        1. Double-click the statement or select the statement and click the Edit button image). An edit dialog box for the particular statement type opens.

        2. Enter the changes you want to make.

        3. Click OK in the edit dialog box.

        4. Click OK or Apply in the Plan window.

          Writing Plans — Printing Plans

          image

      11. Deleting Statements from a Plan

        You can delete statements from a plan individually, or all at once. You can delete the individual statements in the statement block of a conditional statement. If you delete the conditional statement itself, all substatements are also deleted.

        To delete a statement from a plan:

        1. Select the statement you want to delete.

        2. Click the Delete button image) or press Delete.


Deleting All Statements From a Plan

To delete all statements in a plan:

  1. Select the top line in the plan.

  2. Click Delete or press Delete.


    1. Printing Plans

      You can print plans. The printout lists the name of the scenario, the simulation object’s name, and the plan statements.

      To print a plan:

      1. Open a global plan or the Plan window for the simulation object whose plan you want to print.

      2. Choose Plan Print. A standard print dialog box for your operating system opens.

      3. Complete the dialog box as you normally would.


    2. Saving Changes to a Plan

      You can save changes to a plan and continue editing, or save changes and exit the Plan window. The plan is saved to the scenario plan file. You do not specify a file to save it to.

      To save changes to a plan, in the Plan window click Apply or OK.


    3. Building Condition Statements

If you want to add an If block, a While loop, a Wait Until, or a trigger, you must specify a condition to be tested. The conditional expression dialog box is a dynamic dialog box that lets you build a condition. It contains lists that have the permissible options for each step of a condition. As you select options, the dialog box redisplays, adding additional fields. You can build condition statements using comparison opera- tors, logical operators, and tests of simulation object status.

A condition statement can have one condition or many. They can be nested and grouped. In the following sections we explain how to build a simple condition and how to build a complex condition.


      1. Building a Condition Statement that has One Condition

        Although the If/Else Expression, While Expression, Wait Until Expression, and Trigger dialog boxes differ slightly, the process of building a condition is the same for all of them.

        To build a condition statement that has one condition:

        1. On the Conditions menu, choose the type of condition you want to create. The applicable dialog box opens (Figure 36-6). The top line in the condition specifies that all of the conditions are True. Since we are creating a condition statement that just has one condition, this line is largely irrelevant except for the Evaluates To column.


          image

          Figure 36-6. If/Else Expression dialog box

        2. Optionally, in the Description box, type a short summary of the condition.


        3. Optionally, in the Evaluates To list, change the entire condition from True to False.

        4. In the <choose a conditional> list, select the condition that you want to test. If applicable, a dialog box opens for you to specify the parameters of the condition.

        5. Specify the parameters of the condition.

        6. Click OK. The condition is displayed in the display box at the bottom of the dialog box.

        7. Optionally, in the Evaluates To list, change the condition from True to False. Figure 36-7 shows a simple condition.


          image

          Figure 36-7. Simple conditional expression

        8. Click OK. The condition statement is added to the plan or the Trigger pane. In Figure 36-8, note that the If statement uses the text from the description (in Figure 36-7) instead of the full syntax of the condition shown at the bottom of the If/Else Expression dialog box.



          image

          Figure 36-8. Simple conditional expression in a plan


      2. Building a Complex Condition

        You can build condition statements with multiple conditions, nested conditions, and logical operators. The condition expression dialog box displays the syntax of the condi- tion as you build it. The layout of the window shows which conditions are grouped and which are subordinate to others. For an example, of building a complex condition, please see “Complex Condition Tutorial,” on page 36-15.

        To build a complex condition:

        1. On the Conditions menu, choose the type of condition you want to create. The applicable condition expression dialog box opens. The top line in the condition specifies that all of the conditions are True.

        2. Optionally change the top level logical operator to Or.

        3. Optionally change the top level evaluator to False.

        4. In the <choose a conditional> list, select the condition that you want to test. If applicable, a dialog box opens for you to specify the parameters of the condition.

        5. Specify the parameters of the condition.

        6. Click OK. The condition is displayed in the display box at the bottom of the dialog box.

          image

        7. Click the Add button ( ) next to the top line of the condition. A new condition line is added.

        8. Select a condition to test and specify its parameters.

        9. Continue to add conditions as desired. The condition syntax updates as you add conditions.

        10. Optionally, select a new logical operator in the conditions list (And or Or). A subordinate condition line is added under the logical operator and indented.

        11. Add conditions for the logical operator group as you did for the top level logical operator. To simplify the view, you can expand and collapse the logical grouping by clicking the arrow to the left of the logical operator line.

        12. Continue adding conditions as desired.

        13. Click OK.


          Complex Condition Tutorial

          image

          This section walks you through the process of creating a complex condition. It creates the following conditional expression:

          If(“M1A2 4" in area "Area 1" AND ("M1A2 2" left of "Phase Line 1" OR Entity "T80 1" destroyed))then

          else endif

          The procedure assumes a scenario with four M1A2 entities, a T-80, a phase line, and an area.

          To build the condition statement:

          1. Open the Plan window for M1A2 1.

          2. Choose Conditions If. The If/Else Expression dialog box opens (Figure 36-9).


            image

            Figure 36-9. If/Else Expression dialog box

          3. Type a description for the expression you want to build (Figure 36-10).



            image

            Figure 36-10. Description added

          4. In the <choose a conditional> list, select Entity in Area. The Entity in Area dialog box opens.

          5. In the Entity in Area dialog box, select M1A2 4 and Area 1.

          6. Click OK. The condition is added and the If expression is updated (Figure 36-11).


            image

            Figure 36-11. Entity in Area condition added


            image

          7. On the All of the conditions line, click the Add button ( ). A new line is added to the window (Figure 36-12).


            image

            Figure 36-12. Condition added

          8. In the <choose a conditional> list, select Any of the conditions (Or). A new line is added to the window (Figure 36-13).


            image

            Figure 36-13. Or operator and condition added

          9. In the <choose a conditional> list, select Entity Left of Phase Line. The Entity Left of Phase Line dialog box opens.

          10. Select M1A2 2 and Phase Line 1.

          11. Click OK. The condition is added and the If expression is updated (Figure 36-14).



            image

            Figure 36-14. Entity Left of Phase Line condition specified

          12. On the Any of the conditions (Or) line, click the Add button. A new line is added to the window (Figure 36-15).


            image

            Figure 36-15. Last condition line added

          13. In the <choose a conditional> list, select Entity Destroyed. The Entity Destroyed dialog box opens.

          14. Select T80 1.

          15. Click OK. The condition is added and the If expression is updated (Figure 36-16).



            image


            Figure 36-16. Completed expression

          16. In the If/Else Expression dialog box, click OK. The If expression is added to the plan window. Notice that the expression uses the text from the Description box (Figure 36-17).


            image

            Figure 36-17. If expression using condition description

          17. If you did not include a description, the entire syntax of the expression is displayed (Figure 36-18).



            image

            Figure 36-18. If expression using expression syntax


      3. Editing Condition Statements

        To edit an If, While, or Wait Until condition statement:

        1. In the Plan window, double click the statement. The applicable expression building dialog box opens.

          image

        2. To edit the parameters of a condition, click the Edit button ( ) for that condition and change the parameters as desired.

        3. To change the condition being tested, select a different condition in the list and specify its parameters.

          image

        4. To delete a condition, click the Delete button ( ) for that condition.

        5. To change how the condition is evaluated, choose a different option in the Evalu- ates To list.

        6. Click OK.

          To edit a Trigger:

          1. If the Trigger pane is not displayed, click the Expand button image) to show it.

          2. In the Triggers list, select the trigger that you want to edit.

            image

          3. Click the Edit button ( ). The Trigger dialog box opens.

          4. To edit the parameters of a condition, click the Edit button ( image ) for that condition and change the parameters as desired.

          5. To change the condition being tested, select a different condition in the list and specify its parameters.

            image

          6. To delete a condition, click the Delete button ( ) for that condition.

          7. To change how the condition is evaluated, choose a different option in the Evalu- ates To list.

          8. Click OK.


      4. Specifying Names or Patterns in Condition Statements

        Many of the conditions that you can use to build a condition statement require you to specify simulation objects for which the condition will be tested. You can specify:

        The Name and Pattern specifications are mutually exclusive. You cannot specify a name and a pattern. The tab in the Condition dialog box that is visible when you click OK is the specification that gets applied.


        Specifying a Name in a Condition Statement

        To specify a named simulation object in a condition statement:

        1. In a condition dialog box, select the Name tab (Figure 36-19).


          image

          Figure 36-19. Name tab in condition dialog box

        2. Do one of the following:

        3. If you select a unit in the list, the Any Subordinate of Selected Unit check box is enabled. If you want the condition to be satisfied when any member of the unit meets the condition, select the check box.

        4. To specify the inverse of the name, that is, any member except the selected one, select the Invert Selection check box.

        5. Click OK.


Specifying a Pattern in a Condition Statement

The enumerations used in the lists on the Pattern tab are loaded from the file

./appData/settings/vrfGui/condition-entity-types.csv. They represent a subset of the enumerations typically used for simulation objects in simulations. However, you can enter any numeric value you want in the enumeration value box.

If you expect that you will consistently need to specify enumeration values that are not part of condition-entity-types.csv, such as a particular country code, you can edit it to add the patterns you need.

image

To specify a pattern in a condition statement:

  1. In a conditional statement dialog box, select the Pattern tab (Figure 36-20).


    image

    Figure 36-20. Pattern tab in condition dialog box

  2. Optionally, specify a force to test for.

  3. For each element of the enumeration, select an option from the list, or type an enumeration in the text box.

  4. If the enumeration you enter is for a unit, the Any Subordinate Of Selected Unit check box is enabled. If you want the condition to be satisfied when any member of the unit meets the condition, select the check box.

  5. To specify the inverse of the name, that is, any member except the selected one, select the Invert Pattern check box.

  6. Click OK.


image

    1. Using Plan Variables

      Writing Plans — Using Plan Variables

      You can use plan variables in most places where you would select a specific simulation object in a task, set, or conditional test. Plan variables use the names Simulation Object and Created Object. You cannot add your own variables or change the names.

      The variables get assigned values only after an object has been created from within a plan (Created Object) or a conditional test has been met that identifies a simulation object (Simulation Object). If you use a variable in a plan that does not have a value, it is ignored.

      A Simulation Object variable does not get assigned a value until a condition has been completely evaluated. Therefore, you cannot do something like If Entity In Area AND Simulation Object is Destroyed and expect that the Simulation Object variable refers to the entity identified by Entity in Area. In this case, the Simulation Object variable would refer to a previously identified simulation object or it would just be empty.


      image

      i

      i

      Remember that the values assigned to plan variables can change as a simulation object progresses through its plan.


      image


      For conceptual information about plan variables, please see “Plan Variables,” on page 35-15.

      To use a plan variable in plan statement:

      1. In the statement creation dialog box, select Plan Variables in the Filter list. The dialog box lists Created Object and Simulation Object (Figure 36-21).


        image

        Figure 36-21. Plan variables


      2. Select the variable that you want to use.

      3. Complete the rest of the dialog box normally.


    2. Creating Global Plans

      Global plans are not tied to a specific simulation object. However, since they must be executed by a simulation engine, they are assigned to a specific back-end.

      Global plans have a limited set of Task and Set commands and the same set of Commands menu options and conditions as individual plans. (You can add additional tasks using the VR-Forces API or by writing scripted tasks.) You can open an Informa- tion dialog box for a global plan to see its task status and console messages.

      To create a global plan:

      1. Choose Simulation Global Plans. The Global Plans window opens (Figure

        36-22). It lists each global plan and the simulation engine on which it is executed.


        image

        Figure 36-22. Global Plans window

      2. Click New. The New Global Plan Information dialog box opens.

      3. In the Plan Name box, type a name for the plan.

      4. If your scenario has more than one back-end, select the back-end on which you want to run the global plan.

      5. Click OK. The Global Plan window opens (Figure 36-23).

        Writing Plans — Creating Global Plans

        image


        image

        Figure 36-23. Edit Global Plan window

      6. Add commands from the Task, Set, or Conditions menu, as described in “Adding a Task or Set Data Request to a Plan,” on page 36-4 and “Adding an If Block to a Plan,” on page 36-5. Add commands from the Commands menu as described in “Adding Commands to a Plan,” on page 36-29.

      7. Optionally, select the Quick Launch check box to enable quick launching of this plan. For information about using the Quick Launch Toolbar, please see “Controlling When Global Plans Run (Quick Launch),” on page 36-28.

      8. Optionally, select the Show on Quick Launch Toolbar check box to add this global plan to the Quick Launch toolbar.

      9. Optionally, in the Ordinal box, specify the position of this plan on the Quick Launch toolbar.

      10. Optionally, change the icon for this plan on the Quick Launch toolbar, as follows:

        1. Click the Browse button next to the icon name. A file chooser window opens.

        2. Select the file you want to use for the icon.

        3. Click Open.

      11. Click OK.


      1. Controlling When Global Plans Run (Quick Launch)

        If you enable quick launch for a global plan, it does not start executing until you launch it. You can launch it from the Quick Launch toolbar, from the Global Plans window, or from another plan. (You can enable quick launch without putting an icon on the Quick Launch toolbar.) When you launch a global plan, it runs to the end. When it finishes, you can launch it again.


        image

        i

        i

        When the Quick Launch toolbar is docked, it shows an icon for each quick launch item. To find out what the icon represents, mouse over it and read its tooltip. If you undock the toolbar, it displays the name for each quick launch item.


        image

        To launch a global plan from the Quick Launch toolbar, click its icon.

        To launch a global plan from the Global Plans window:

        1. Choose Simulation Global Plans. The Global Plans window opens (Figure 36-22).

        2. Select the global plan you want to launch. If it is not running, the Launch button becomes active.

        3. Click Launch. The global plan runs. When it completes, the Launch button becomes active again.

          To launch a global plan from a plan:

          1. Open the plan window for an individual plan or a global plan.

          2. Choose Commands Launch Global Plan. The Launch Global Plan window opens.

          3. Select the global plan you want to launch.

          4. Click OK.


      2. Opening an Information Dialog Box for a Global Plan

        To open an Information dialog box for a global plan:

        1. Choose Simulation Global Plans. The Global Plans window opens (Figure 36-22).

        2. Select the global plan for which you want to open an Information dialog box.

        3. Click Information.


36.7. Adding Commands to a Plan

The Commands menu lets you assign tasks and set data requests to simulation objects and create the objects on the Simulation Objects Palette, Tactical Graphics Palette, and Hazards/Obstacles Palette. There are also several commands that are only available on the Commands menu. Except as noted in this section, the procedures for adding global commands and conditional statements to a global plan are the same as the procedures for adding them to individual plans.


image

i

i

Since a global plan has no idea what type of simulation object you might want to give a task or set data request to, when you add a task or set, the full list of possible tasks and sets is available. There is no context sensitivity like there is when you select a simulation object and view the Task or Set menu. It is up to you to be sure that the task or set you are assigning to a simulation object is supported by that object.

The best way to determine this is to create a simulation object of the type to which you want to give a task and see if the task or set data request is available on its context-sensitive Task or Set menu. You can also check Appendix D, Systems and System Usage to see if a simulation object type has the system used for a particular task.


image


      1. Adding Tasks and Sets from the Commands Menu

        The commands on the Task and Set menus in an individual plan apply implicitly to the simulation object for whom you are writing a plan. Tasks and sets on the Commands menu must be assigned explicitly to a target simulation object.

        Other than the requirement to specify the target simulation object, adding a global task or set command to a plan uses the same procedure as adding any task or set to an indi- vidual plan.

        To assign a task from the Commands menu:

        1. In a Plan window or Global Plan window, choose Commands Task. The Task dialog box opens (Figure 36-24).



          image

          Figure 36-24. Task dialog box


          image

          i

          i

          The procedure for adding a set data request is the same as for a task, except that you choose Commands Set and the Set dialog box opens.


          image


        2. In the Apply Command To group box, select a simulation object from the list or type its name in the Name box. The simulation object does not have to exist in the scenario at the time you add the command, but you should be sure that it will be created before the command is run. The window displays a list of tasks for the selected simulation object (Figure 36-25). If the simulation object already exists in the scenario, the list of tasks is context-sensitive.



          image

          Figure 36-25. Task list


          image

          i

          i

          Remember that a command task affects a simulation object like an independent task. It interrupts the current task and causes the simulation object to abandon its plan. If you are adding a command to an individual plan, be sure that you are assigning it to some other simulation object and not the simulation object for whom you are writing the plan. (Unless you want the simulation object to abandon its plan.)


          image


        3. Select the task you want to assign.

        4. Click OK. If the task takes parameters, a dialog box opens.

          If the task does not take parameters, such as Wait, the command is added to the plan.

        5. If the task takes parameters, specify the parameters and click OK in the task- specific dialog box. Please see Chapter 26, Assigning Tasks through Chapter 31, Tasks for Aggregate-Level Scenarios and Chapter 34, Setting the State of Simulation Objects for the details of assigning specific tasks and sets.

        6. Click OK. The command is added to the plan.


          Editing Task and Set Commands in Plans

          If you want to edit a task or set command in a plan, you can:

          • Delete the plan statement and start over.

          • Edit the existing statement. If you edit the existing statement, you can:

            • Delete the current task and choose a different one.

            • Edit the parameters of the task.

          To edit a task or set command in a plan:

          1. Select the plan statement you want to edit.

          2. Click the Edit button, or double-click the statement. The Send Task or Send Set dialog box opens. The task list is grayed out. If you are not sure of the task that you are editing, you can read the text of the command below the window (Figure

            36-26).


            image

            Figure 36-26. Send Radio Task dialog box for plan command

            image

          3. To clear the task and start over, click the Delete button ( ).

            image

          4. To keep the same task and change the parameters, click the Edit button ( ). The appropriate dialog box opens and you can edit the parameters.

          5. Click OK.


      2. Sending Console Messages

        You can send messages to be displayed in the console on an object’s Information dialog box and to the back-end console. Messages sent by global plans go to the back-end console. Messages sent from a simulation object’s plan go to the console in its Informa- tion dialog box.

        If the notification level for a console message is lower than the notification level config- ured for the back-end or the target simulation object, the message is not displayed. For example, if a simulation object’s notification level is set to Info, it receives Error, Warn, and Info messages, but not messages set to Verbose or Debug.

        To send a console message from a plan:

        1. In a plan window, choose Commands Console Message. The Console Message dialog box opens.

        2. Select the notify level from the list.

        3. Type the message you want to send.

        4. Click OK.


      3. Creating Objects from Within a Plan

        You can create any of the objects on the Simulation Objects, Tactical Graphics, and Hazards/Obstacles palettes from within a plan.

        To create an object from a plan:

        1. In a plan window, choose Commands Create palette, where palette is one of the object creation palettes. The selected palette opens.

        2. Select the object you want to create.

        3. Create the desired object as you would if you were creating it directly from one of the object creation palettes. When you are finished creating the object, a Create command is added to the plan and the object itself disappears. (The object disap- pears because you are not actually creating the object right now, you are just creating the command that will create it when the plan executes.)


      4. Deleting Objects from Within a Plan

        You can delete any object in a scenario from a plan.

        To delete an object from a plan:

        1. In a plan window, choose Commands Delete Object. The Delete Object dialog box opens.

        2. Type the name of the object you want to delete or select the object in the list or on the terrain.

        3. Click OK.


          Deleting One’s Self from the Scenario

          The Delete Object global command lets you delete any specified object. If you just want to delete the simulation object whose plan you are editing, you can use the Delete Self command. Like the Use Self option in some conditions, Delete Self provides a non- entity-specific command that is useful for plans that you want to assign to multiple simulation objects.

          To assign the Delete Self command, choose Commands Delete Self.


      5. Issuing a Plan

        The Issue Plan global command lets you assign a plan to a simulation object. When you issue a plan, the new plan replaces whatever plan or task the simulation object is executing. Although you can issue a plan to any simulation object, this command is particularly useful when you create a simulation object after a scenario has started.

        When you create a scenario, you cannot create a plan for a simulation object that does not exist. Therefore, if you create a simulation object after the scenario starts (using the Create global command), it is difficult to send it a sequence of tasks because global commands are not executed in sequence (as discussed in “Introduction to Individual Plans and Global Plans,” on page 35-2). The Issue Plan command solves this problem.

        Issue Plan is a concurrent task. Including it in a plan does not affect the current task that the simulation object is executing or the sequencing of tasks in its plan.

        To issue a plan to a simulation object:

        1. In a plan window, choose Commands Issue Plan. The Issue Plan dialog box opens (Figure 36-27).


          image

          Figure 36-27. Issue Plan dialog box


        2. In the Apply command To: group box, select the simulation object to which you want to assign this plan or type the name of the simulation object in the Name text box. If this is a simulation object that does not yet exist (because you plan to create it after the scenario starts), you must type the name and you are responsible for ensuring that the name you type matches the name of the simulation object that gets created.

        3. Use the right side of the dialog box to write a plan. It has the exact same set of menus and commands as the Plan dialog box. Follow the procedures described else- where in this chapter to write the plan.

        4. Click OK.


      6. Sending View Control Messages

        You can send view control messages to set the view mode for observers in the simula- tion. This includes the observers in VR-Forces and those in any other VR-Vantage applications in the exercise. When you send a command you can direct it to a specific observer or to all similarly named observers, for example, all Observer 1s.

        The Observer View command works only with VR-Forces. It does not affect other VR- Vantage applications. If you send the Observer View command, you can specify a tran- sition time to the new view, similar to the automated transition described in “Animating Transitions Between Observer Views,” on page 49-32.


        image

        i

        i


        image


        To send a view control message:

        1. In a plan window, choose Commands Send View Control. The Send View Control window opens (Figure 36-28).

        2. Select an Observers to Control option. Observer 1 sends the view control command to Observer 1 in all VR-Vantage applications. If you want to direct the view control message to a particular observer:

          1. Select Specific. The dialog box expands to show a list of observers.

          2. Select the observers you want to control by object name (such as 1:3101 Observer 1) or by observer name (such as Observer 2).

          3. Click OK.


            image

            Figure 36-28. Observers to control

        3. In the View Action list, select the view control you want to send, as follows:

          • Reset. Reset the observer view to the default view.

          • Detach. Detach the observer from an attached simulation object.

          • Observer View. Sends the selected observer view (from the Observer Views Panel).

          • Attach mode, where Attach mode is Absolute or one of the attach modes. Sends the selected attach mode.

          For every command except Reset and Detach, the dialog box redisplays to add a selection window appropriate to the view mode.

        4. If you selected Observer View as the View Action, select the observer view that you want to send (Figure 36-29). Optionally, specify a transition time, in seconds.



          image

          Figure 36-29. Observer view

        5. If you selected Absolute mode or an attach mode as the View Action, complete the dialog box (Figure 36-30) as follows:

          1. In the Observer Mode list, select the observer mode for the view control message.

          2. If you selected Absolute mode, specify the location of the observer and, option- ally, an offset orientation.

          3. If you selected an attach mode, select the simulation object to attach to.

          4. If you selected an attach mode that supports an offset vector or offset orienta- tion, optionally select Manual and specify an offset. The default offset is 0,0,0.


            image

            Figure 36-30. Attach mode

          5. If you select Track, specify the location for the observer to track from.

          6. If you select Tether Track, select a secondary simulation object and, optionally, a position offset.

        6. Click OK.

Writing Plans — Writing Plans for Remote Entities

image

    1. Writing Plans for Units

      To write a plan for a unit:

      1. Select the unit.

      2. Follow the procedures for writing a plan for an individual simulation object.


        image

        i

        i

        Please see “Independently Tasking Unit Members,” on page 26-12 for notes about how simulation objects that are members of units respond to individual plans and independent tasks.


        image


    2. Writing a Plan for Multiple Simulation Objects

      You can write a plan and assign it to multiple simulation objects at the same time. If any of the simulation objects already has a plan, it is overwritten by the new plan. After you assign a plan using this procedure, you can subsequently edit the plans for partic- ular simulation objects and the changes do not affect the other simulation objects.


      image

      i

      i

      If you select several simulation objects and they all have the exact same plan, the plan window displays that plan. If any of the simulation objects have different plans, you are given the option to continue or cancel. If you continue, VR-Forces displays an empty Plan window and the new plan replaces whatever plans the simulation objects previously had.


      image


      To write a plan for multiple simulation objects:

      1. Select the simulation objects to which you want to assign the same plan.

      2. Choose Objects Plan. The Plan window opens.

      3. Add statements to the plan as you would if you were writing a plan for an indi- vidual simulation object.

      4. Click OK. The plan is assigned to the selected simulation objects.


    3. Writing Plans for Remote Entities

      If you attach components to remote entities, you can write plans for those entities. To assign plans, the entities must exist in the exercise, must have attached components, and must be present in the exercise when VR-Forces saves the scenario. The plans must be appropriate for the attached components. Movement tasks are not appropriate, because VR-Forces cannot control the location of a remote simulation object. Appro- priate plan statements might be to enable spot reporting, or to send a radio message. For details about how to attach components to remote entities, please see “Attaching VR-Forces Components to Remote Entities,” on page 76-2.

      Writing Plans — Copying Plans and Plan Statements

      image

    4. Copying Plans and Plan Statements

      You can copy plans and individual plan statements and paste them elsewhere in a plan or into another simulation object’s plan.


      image

      i

      i

      In addition to copy and paste, you can drag statements and condition blocks from one location to another in a plan and to other plans.


      image


      To copy plans and plan statements:

      1. Open the Plan window for the plan that you want to copy.

      2. To copy the entire plan, select the top line in the plan (Plan). To copy a statement, select the statement. If you select a conditional statement, the entire statement block is selected.

      3. Choose Plan Copy Plan or click the Copy button image).

      4. Open the Plan window for the simulation object you want to copy the plan to.

      5. Select the line just above where you want to insert the copied plan.

      6. Click the Paste button image).

      7. Continue editing the plan.

      8. Save the plan.


        image

    5. Restarting a Plan

      Writing Plans — Restarting a Plan

      There may be occasions when you want to restart a simulation object’s plan without restarting a scenario. You can restart a plan interactively or by placing a Restart Plan command in a plan.

      When you restart a plan, VR-Forces processes the statements in the plan, starting from the first statement. However, the simulation object executes tasks starting from its current location, not the location it had at the start of the scenario (unless it has not moved since the start of the scenario).

      To restart a plan interactively:

      1. Select the simulation object whose plan you want to restart.

      2. Choose Objects Restart Plan. To restart a plan from within a plan:

        1. Open a simulation object’s plan or a global plan.

        2. Choose Commands Restart Plan. The Restart Plan dialog box opens.

        3. Select the simulation object whose plan you want to restart.

        4. Click OK.

        5. Save the plan.

        To restart a plan from the Plan window:

        1. Open a simulation object’s plan.

        2. Click Restart.

        Writing Plans — Abandoning a Plan

        image

    6. Abandoning a Plan

      If you give a simulation object that is executing a plan an independent task, it abandons the plan. You can also order a simulation object to stop executing its plan. When you abandon a plan, the following things happen:

      • The simulation object stops whatever task it is working on, even if it is an indepen- dent task.

      • The plan is marked as complete.

      • All registered triggers are deleted.

      • The statement indicator skips to the end of the plan.

      • The simulation object enters a wait state.


      image

      i

      i

      If you give a simulation object that is executing a plan an independent task, VR-Forces prompts you before it abandons the plan. (There is no prompt for the Abandon Plan command.) You can disable the prompt. For details, please see “Enabling and Disabling the Task Confirmation Prompt,” on page 26-6.


      image


      You can abandon a plan interactively or by sending an Abandon Plan command in an individual or global plan.

      To abandon a plan interactively:

      1. Select the simulation object whose plan you want to abandon.

      2. Choose Objects Abandon Plan. To abandon a plan from within a plan:

  1. Open a simulation object’s plan or a global plan.

  2. Choose Commands Abandon Plan. The Abandon Plan dialog box opens.

  3. Select the simulation object whose plan you want to abandon.

  4. Click OK.

  5. Save the plan.

To abandon a plan from the Plan window:

  1. Open a simulation object’s plan.

  2. Click Abandon.


image

  1. Tactical Graphics


    Tactical graphics are objects that represent points, lines, areas, and information overlaid on the terrain. This section describes overlays and particular details about tactical graphics. For generic information about creating tactical graphics, please see Chapter 16, Creating and Placing Objects. For information about combat engineering objects, which are displayed similarly to tactical graphics, please see “Combat Engineering Objects,” on page 23-9.



    VR-Forces Users Guide

    Section VII - Tactical Graphics


    VII-1

    Tactical Graphics

    image


    Section VII - Tactical Graphics

    VII-2 VT MAK


    image 37. Introduction to Tactical Graphics


    This chapter is a brief introduction to tactical graphics.

    Introduction 37-2

    Points 37-4

    Phase Lines 37-4

    Routes 37-5

    Areas 37-5

    Obstacles 37-5

    Displaying Tactical Graphics 37-6

    Showing and Hiding Tactical Graphics 37-8

    Showing and Hiding Tactical Graphics Labels 37-9

    Displaying Height-Above-Terrain Lines for Vertices 37-10

    Introduction to Tactical Graphics — Introduction

    image

      1. Introduction

        VR-Forces lets you add tactical graphics to scenarios. Tactical graphics are objects that represent points, lines, areas, and information overlaid on the terrain. They are auto- matically assigned to overlays. (You can configure the default overlay assignments and can change the overlay at or after creation.) Simulation objects have knowledge of some types of tactical graphics, which allows tasks and plans to take them into account. VR- Forces supports the following types of tactical graphics:

      2. Points

        A point identifies an X, Y, Z coordinate in the terrain. You can command a simulation object to travel to a point and to travel back and forth between points. Figure 37-1 illustrates waypoints in the 3D and 2D views. In 3D, the bottom of the symbol points to the location of the waypoint. In 2D, it is centered. You can place several different kinds of points on overlays.

        image

        A point can have an altitude value. This allows you to send aircraft to waypoints or have them patrol between points.


        image

        Location of waypoint


        3D 2D


        Figure 37-1. Waypoint symbol


      3. Phase Lines

        A phase line is defined by two points, but is considered to extend indefinitely in either direction and have infinite height. A phase line is used to test the location of a simula- tion object, for example: Is simulation object A to the left of phase line B? The left side of the line is determined relative to the direction in which the line is drawn. A phase line’s label is placed at the beginning of the line. Therefore, you can always determine which side of a line is the left side. Figure 37-2 illustrates two phase lines. The arrows are placed to the left of the line and indicate the direction of the line.


        image

        i

        i

        Simulation objects cannot move along phase lines, so do not create a phase line if you want a two point route.


        image


        image


        image

        Phase Line 1


        image

        image

        Phase Line 2

        Figure 37-2. Phase line direction


        image

      4. Routes

        Introduction to Tactical Graphics — Obstacles

        A route is a sequence of points in three-dimensional space. Like phase lines, routes have a direction. A line’s name is displayed at its beginning.

        Simulation objects can move along routes from one end to the other, and can patrol back and forth along them.


        image

        i

        i

        • Do not create a two-point route if you want a phase line. VR-Forces cannot determine whether a simulation object is to the left or right of a route.

        • Many “line” tactical graphics are treated as routes by simulation objects.


          image


      5. Areas

        An area defines a polygonal area on the terrain. (This is not a terrain polygon, it is just a graphic.) An area is used to test the location of a simulation object, for example: Is simulation object A in area B?


      6. Obstacles

        Obstacles represent lines and areas of the terrain that would cause a simulation object problems, such as a ditch or minefield. In entity-level scenarios, if obstacle avoidance is enabled, if a ground entity encounters an obstacle in its path, it tries to drive around the obstacle.

        In addition to obstacles, aggregate-level scenarios support combat engineering objects and contamination areas. These objects can defend, damage, or impede simulation objects.

        Obstacles and linear obstacles are on the Hazards/Obstacles palette in entity-level scenarios. Obstacles (areal) are on the Tactical Graphics palette in aggregate-level scenarios. (The many combat engineering objects available in aggregate-level scenarios make simple obstacles comparatively less useful.) Linear obstacles are not supported in aggregate-level scenarios. They only work in navigation areas.


      7. Displaying Tactical Graphics

        You can configure the display of tactical graphics as follows:

        • Enable and disable the display of tactical graphics.

        • Show or hide vertex indicators for point, linear, and areal objects.

        • Show or hide height-above-terrain lines.

        • Display height-above-terrain lines only for selected graphics.



    image

    Vertex indicator HAT line Height Route


    Figure 37-3. Tactical graphics with height-above-terrain lines (3D)


    image

    Figure 37-4. Tactical graphic (2D)


        1. Showing and Hiding Tactical Graphics

          You can control the display of tactical graphics from the Display Settings dialog box, Tactical Graphics Display Settings page, from menu and toolbar options, and from the Overlays tab.

          To show or hide tactical graphics:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Tactical Graphics Display Settings page (Figure 37-5).



            image

            Figure 37-5. Tactical Graphics Display Settings page

          3. Select or clear the Show Tactical Graphics check box.

          4. To show only active tactical graphics, select Show Only Active Tactical Graphics. For more information about active tactical graphics, please see “Active and Inactive Tactical Graphics,” on page 39-19.


            image

            image

            i

            i

            You can also enable and disable tactical graphics by choosing Settings Tactical Graphics or clicking the Tactical Graphics button ( ) on the Display Settings Toolbar.


            image


            Showing and Hiding Tactical Graphics on the Overlays Tab

            On the Overlays tab, you can show and hide tactical graphics individually and by overlay.

            To control the display of tactical graphics from the Overlays tab:

            1. On the Objects List Panel, select the Overlays tab (Figure 38-2).

            2. To hide all graphics on a particular overlay, clear the check box for that overlay.

            3. To hide a specific tactical graphic, clear its check box.

            4. To redisplay a hidden tactical graphic or overlay, select its check box.


        2. Showing and Hiding Tactical Graphics Labels

          In addition to displaying the outlines of tactical graphics, you can display graphics (labels) for the vertices of these objects. Vertex labels are enabled in Figure 37-3 and Figure 37-4. In Plan View mode, VR-Forces also displays a tactical graphic’s name, label, and extended labels, if any. For details about displaying labels for 2D icons, please see “Displaying Labels for 2D Icons,” on page 18-14.


          image

          i Displaying vertex labels can affect performance.

          image

          To show or hide vertex labels:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Tactical Graphics Display Settings page (Figure 37-5).

          3. Select or clear the Show Tactical Graphics Labels check box.


          image

          i

          i

          You can also enable and disable tactical graphics labels by choosing Settings

          Tactical Graphics Labels or clicking the Tactical Graphics Labels button image) on the Display Settings Toolbar.


          image


        3. Displaying Height-Above-Terrain Lines for Vertices

          In 3D observer modes, you can display height-above-terrain (HAT) lines for the vertices of tactical graphics (Figure 37-3). These vertical lines between an object’s vertices and the ground help you understand the relationship of the object to the terrain. The height for each vertex is displayed (using whatever units are configured on the Display Units Settings page).

          HAT lines are shown only for tactical graphics that could be above or below the ground, such as routes, and waypoints. You can show and hide these lines and you can specify that they be shown for all objects or only for the selected objects.


          image

          ! Use of height above terrain lines can reduce the frame rate.

          image

          To show or hide height-above-terrain lines:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Tactical Graphics Display Settings page (Figure 37-5).

          3. To display HAT lines, select the Enable Height Above Terrain Lines check box.

          4. To only display lines for selected objects, select the Only Display Height Above Terrain Lines For Selected Tactical Graphics check box.


    image

    38. Overlays


    This chapter explains how to create and edit overlays.

    Creating and Editing Overlays 38-2

    Creating an Overlay 38-3

    Selecting Overlays 38-3

    Locking an Overlay 38-3

    Hiding the Objects on an Overlay 38-4

    Changing an Overlay’s Name 38-4

    Deleting an Overlay 38-5

    Saving and Loading Tactical Graphics and Overlays 38-5

    Loading Tactical Graphics and Overlays 38-5

    Exporting Tactical Graphics as Shapefiles 38-6

    Importing Shapefiles into Overlays 38-7

      1. Creating and Editing Overlays

        Overlays allow you to add graphic objects to the VR-Forces window as if you were adding clear plastic overlays to a physical map and drawing on them. They provide a convenient way to organize and manage the tactical graphics and simulation objects in a simulation. You can add any number of overlays. You can rename them. You can enable or disable editing of the objects they contain.

        When you create an object, if you do not explicitly assign it to an overlay, it gets placed on a default overlay. If the default overlay does not exist, it gets created. The default overlay for an object type is configured in the Simulation Object Editor.

        Overlays and their contents are displayed in the Overlays tab of the Objects List Panel. The Overlay Bar has a label for each overlay that lets you show and hide the objects on that overlay (Figure 38-1).


        image

        Figure 38-1. Overlays tab and Overlay Bar

        Overlays — Creating and Editing Overlays

        image

        1. Creating an Overlay

          To create an overlay:

          1. On the Objects List Panel, select the Overlays tab (Figure 38-2).


            image

            Figure 38-2. Overlays tab

            image

          2. Click the Add button ( ). An overlay is added to the list with a default name.

          3. Optionally, change the name as described in “Changing an Overlay’s Name,” on page 38-4.


        2. Selecting Overlays

          To select an overlay, click its name on the Overlays tab.


        3. Locking an Overlay

          When an overlay is locked, you cannot edit the objects on it. You can still add and delete objects.

          To lock or unlock an overlay:

          1. On the Objects List Panel, select the Overlays tab.

          2. Select the overlay you want to lock or unlock.

          3. Click the Lock/Unlock button ( image), or double-click the entry in the Locked column. It will toggle between Yes and No.


        4. Hiding the Objects on an Overlay

          You can hide the objects on an overlay. This may be convenient if you want to focus on a particular set of simulation objects or tactical graphics while you are editing or observing a scenario. You can hide all of the objects on an overlay or individual objects.

          To hide all of the objects on an overlay, do one of the following:

          • Click the overlay’s tab on the Overlay Bar.

          • On the Objects List Panel, Overlay tab, clear the check box for the overlay that you want to hide.

          To hide individual objects on an overlay, on the Objects List Panel, Overlay tab, clear the check box for the object.


          Hiding an Overlay by Default

          You can mark overlays so that they are hidden when a scenario loads, when you add a simulation object group, or when you import a scenario.

          To hide an overlay by default, place an asterisk(*) at the start of the name, for example, *Tactical Graphics.


        5. Changing an Overlay’s Name

          You can change the name of a default overlay, such as Entities or Tactical Graphics. However, the next time you create an object that gets assigned to a default overlay, unless you assign it to the renamed overlay, a new overlay with the default name gets created.

          To change an overlay’s name:

          1. On the Objects List Panel, select the Overlays tab.

            image

          2. Select the overlay that you want to rename and click the Rename button ( ), or double-click the overlay whose name you want to change. The name becomes edit- able.

          3. Type a new name.

          4. Press Enter.

            Overlays — Saving and Loading Tactical Graphics and Overlays

            image

        6. Deleting an Overlay

          To delete an overlay:

          1. On the Objects List Panel, select the Overlays tab.

          2. Select the overlay you want to delete.


            image

            !

            !

            When you delete an overlay, all of the simulation objects and tactical graphics on it are also deleted.


            image


            image

          3. Click the Delete button ( ).


      1. Saving and Loading Tactical Graphics and Overlays

        If you publish a tactical graphic, it is automatically saved to the order of battle file (.oob). If you do not publish a tactical graphic, it is automatically saved to the overlay file (.ovl). There may be cases where you want to create a set of overlays for use in multiple scenarios. You can save them to an overlay file independently of the scenario, or even save the overlays and not save the scenario at all.


        image

        i When you save overlay objects, only unpublished tactical graphics get saved.

        image

        To save overlays and tactical graphics:

        1. Choose File Save Overlay. The Save Overlay dialog box opens.

        2. Type a name for the overlay file.

        3. Click Save.


          38.2.1. Loading Tactical Graphics and Overlays

          You can load overlays that you have saved from a previous session.

          To load overlays:

          1. Choose File Load Overlay. The Load Overlay dialog box opens.

          2. Select the overlay file you want to load.

          3. Click Open.


          image

          !

          !

          When you load overlay objects, you must use the same terrain database you created them on, or a terrain database that includes the area they were created in.


          image


      2. Exporting Tactical Graphics as Shapefiles

        You can export point, line, and area tactical graphics to shapefiles. VR-Forces exports all of the graphics on a selected overlay. This may be useful if you need feature data for a terrain, such as a road network, but there is no feature data available from external sources. You can edit the shapefile created by VR-Forces in an appropriate third-party application to add the attributes needed to fully specify the features. For example, suppose you need a road network. You would create routes in the proper locations in VR-Forces and export the overlay to a shapefile. Then you would edit the shapefile to connect the road segments, specify road width, number of lanes, and so on. You could then load the shapefile in VR-Forces or any other application that supports shapefiles.

        When VR-Forces creates shapefiles from tactical graphics, it creates separate files for points, lines, and areas. It appends P.shp, L.shp, or A.shp to the filename you provide based on the tactical graphics types being exported. For example, if an overlay has points and lines and you export them to myFeatures, VR-Forces creates files called myFeaturesP.shp and myFeaturesL.shp.

        To export tactical graphics as shapefiles:

        1. On the Objects List Panel select the Overlay tab.

        2. Select the Overlay whose tactical graphics you want to export.

        3. Choose File Save Overlay as Shape Files. The Save Overlay as Shape Files dialog box opens. (You can also right-click an overlay tab and open the context-sensitive menu.)

        4. Type a name for the shapefile.

        5. Click Save.

        Overlays — Exporting Tactical Graphics as Shapefiles

        image

        1. Importing Shapefiles into Overlays

          You can import feature data into overlays. Features are placed as points, lines, or areas. This is a quick way to create tactical graphics for features such as roads, buildings, and so on. For example, if you were to load the MAK Earth (online).mtf terrain and import BuildingsP.shp, which is used in the Little Pond terrain, it places a group of waypoints at the locations of the buildings. (For more information about BuildingsP.shp, please see “Add a Feature Layer,” on page 63-9.)


          image

          i

          i

          Importing shapefiles into an overlay is not the same thing as adding a feature layer to the terrain. For example, importing a file such as RoadsL.shp to an overlay creates routes that can be referenced in movement tasks. Adding it as a feature layer creates a road network that could be used for path planning.


          image


          To import feature data into an overlay:

          1. Select an overlay.

          2. Choose File Import Shape File Onto Overlay. The Import Shapefile Onto Overlay dialog box opens.

          3. Select the shapefile you want to import.

          4. Click Open.


    image

    39. Creating and Editing Tactical Graphics


    This chapter explains how to create and edit overlays and tactical graphics.

    Creating Tactical Graphics 39-2

    Creating Freehand Lines 39-2

    Drawing Circles and Ellipses 39-3

    Drawing Boxes 39-3

    Creating Volumetric Tactical Graphics 39-4

    Adding Text to an Overlay 39-5

    Assigning Tactical Graphics to an Overlay 39-5

    Displaying a Terrain Profile When You Create a Line 39-6

    Publishing Tactical Graphics 39-7

    Creating a Computed Route 39-7

    Creating an Intel Collection Area 39-9

    Creating Routes for Aircraft 39-10

    Attaching Tactical Graphics to a Simulation Object 39-11

    Attaching a Tactical Graphic Automatically 39-11

    Deleting Tactical Graphics 39-11

    Editing Tactical Graphics 39-12

    Editing Vertices 39-13

    Resizing Boxes and Text Objects 39-15

    Rotating an Ellipse 39-16

    Changing the Direction of a Line 39-16

    Changing the Color of a Tactical Graphic 39-16

    Using the Force Color for Vertices 39-17

    Changing Linear and Areal Style Properties 39-17

    Active and Inactive Tactical Graphics 39-19

      1. Creating Tactical Graphics

        The generic procedures for creating tactical graphics are described in Chapter 16, Creating and Placing Objects. This section provides additional details about tactical graphic creation and placement.


        1. Creating Freehand Lines

          A freehand line is essentially many short line segments. After you create a freehand line you can change the sampling rate used to determine how many segments it has. The fewer the segments, the less fluid the line is.

          Unlike other lines, the individual vertices of a freehand line do not have vertex markers. You cannot select them individually on the map. However, you can edit them in the Edit Freehand Line dialog box.

          The Freehand Line With Arrow tactical graphic automatically puts an arrow at the end of the line. However, you can also add an arrow to a freehand line that is created without one.


          image

          i

          i

          If you reduce the sampling rate, resulting in fewer segments and a less fluid line, once you save the line you cannot automatically increase the number of segments to increase the fluidity of the line. You would have to add vertices by hand.


          image


          To create a freehand line:

          1. Click the Tactical Graphics Palette.

          2. Select the Shapes category.

          3. Select Freehand line or Freehand Line with Arrow.

          4. Click where you want the line to start, and while holding down the left mouse button, draw a line on the screen.

          5. Release the mouse button. The Create Freehand dialog box opens.

          6. Edit the properties as desired.


        2. Drawing Circles and Ellipses

          Simulation objects do not interact with circles and ellipses. They are strictly for use as graphics.

          To draw a circle:

          1. Click the Tactical Graphics Palette.

          2. Select the Shapes category.

          3. Select Circle. The cursor changes to draw mode and shows a vertex icon.

          4. Click to place the center of the circle. A center point is placed on the terrain and a circle is drawn. There is now a vertex icon on the circumference of the circle.

          5. Drag the mouse to set the radius of the circle.

          6. Click to complete the circle.

            To draw an ellipse:

            1. Click the Tactical Graphics Palette.

            2. Select the Shapes category.

            3. Select Ellipse. The cursor changes to draw mode and shows a vertex icon.

            4. Click to set the center of the ellipse. A center point is set and a small circle is displayed with a vertex indicator at the bottom of the circle.

            5. Drag the mouse up or down and click to set the height of the ellipse. A vertex indi- cator is added to the left side of the circle.

            6. Drag the mouse left and right and click to set the width of the ellipse.


        3. Drawing Boxes

          Boxes are constrained to be parallelograms. Simulation objects do not interact with boxes. (In other words, they are not areas.)

          To draw a box:

          1. Click the Tactical Graphics Palette.

          2. Select the Shapes category.

          3. Select Box. A box is attached to the cursor

          4. Click to place the box in the approximate location that you want.

          5. Double-click any vertex. The vertex changes to show it is editable.

          6. Drag the vertex to reshape the box.


        4. Creating Volumetric Tactical Graphics

          You can create volumetric tactical graphics. Volumetric tactical graphics are useful for defining air corridors, airspace, and similar 3D areas. You can create the following volu- metric graphics:

          • Area (extruded).

          • Box (extruded).

          • Circle (extruded).

          • Corridor (a linear object).

          • Ellipse (extruded).

          Volumetric areal objects have a floor and a ceiling above the terrain. Corridors have a width and height, which are centered on the vertices. Simulation objects can move along a corridor. (They move along the center line and ignore the height and width.)

          The Entity in Area condition can check to see if an entity is within the volume of an extruded area.

          To create a volumetric tactical graphic:

          1. Click the Tactical Graphics Palette.

          2. Select the volumetric tactical graphic you want to create.

          3. Specify the vertices of the tactical graphic just like you would for a 2D tactical graphic. When you right-click to set the final vertex, the Edit dialog box should open.

          4. If the Edit dialog box does not open, click its tab to open it.

          5. If you are creating a route, specify the height and width. If you are creating any other extruded tactical graphic, specify the floor and ceiling (above mean sea level).

          6. Click Create.


        5. Adding Text to an Overlay

          You can add text to an overlay. The maximum width of the text object is fixed.

          To add text to an overlay:

          1. Click the Tactical Graphics Palette.

          2. Select the Shapes category. (Text is also in the Logistics, Intel, and Symbols catego- ries.)

          3. Select Text. The text “Text” is attached to the cursor.

          4. Click to set the bottom center of the text. The Create Text dialog box opens.

          5. Type the text you want in the Text box.

          6. Edit any other properties as desired.

          7. Click Create.


        6. Assigning Tactical Graphics to an Overlay

          By default, when you create a tactical graphic, it gets assigned to an overlay with the same name as the palette from which it is created. (You can change the default overlay in the Simulation Object Editor.) If no overlay exists, the overlay is created and the graphic is assigned to it. You can assign a tactical graphic to a different overlay when you create it or edit it. To assign a tactical graphic to an overlay when you create it, set this property as described in “Specifying an Object’s Properties Before You Create It (Click to Locate),” on page 16-13. To move a tactical graphic to a different overlay, follow the procedure in “Moving a Tactical Graphic to a Different Overlay,” on

          page 39-5.


          Moving a Tactical Graphic to a Different Overlay

          To move a tactical graphic to a different overlay:

          1. Select the tactical graphic you want to move.

          2. Choose Objects Edit. The Edit Object dialog box opens.

          3. If Attach Object to Mouse is selected, clear the check box.

          4. In the Overlay list, select the overlay that you want the tactical graphic to move to.

          5. Click Update.


            image

            i

            i

            You can also move a tactical graphic to a different overlay by dragging it to the new overlay on the Overlays tab of the Objects List panel.


            image


        7. Displaying a Terrain Profile When You Create a Line

          You can display a terrain profile window while you create a line. You can configure VR- Forces to automatically display a terrain profile when a line is created (“Configuring Terrain Profiles,” on page 54-3), or you can display the window manually.

          To open a terrain profile window while you are creating a line:

          1. Select the tactical graphic that you want to create as described in “Selecting the Object to Create,” on page 16-4. A Create Object tab is added to the window below the Props Palette (Figure 16-4).

          2. Click the Create Object tab. A Create Object dialog box that is appropriate for the object opens (Figure 39-1).



            image

            Figure 39-1. Terrain Profile button

          3. Click to place the first vertex. The Terrain Profile button is activated.

          4. Click Terrain Profile. A terrain profile window opens.

          5. Complete the line. The terrain profile window stays open until you complete the line.


        8. Publishing Tactical Graphics

          By default, all tactical graphics are published. That is, they are sent out over the network and are visible to other participants in an exercise. You can choose to not publish a tactical graphic. In that case, it is visible only in the front-end on which it was created.

          Published tactical graphics get saved to the order of battle file. Unpublished tactical graphics get saved to the overlays file that gets created as part of the scenario. You can also manually save tactical graphics to an overlay file separate from the one stored with the scenario.

          To publish or unpublish a tactical graphic:

          1. Select the graphic you want to edit.

          2. Choose Objects Edit. The Edit Object dialog box opens.

          3. To publish the object, select the Publish Object check box. To unpublish it, clear the check box.


        9. Creating a Computed Route

          VR-Forces can create routes between two points and take into account criteria such as avoiding buildings, using roads, and avoiding water. Unlike the temporary routes that VR-Forces creates for movement tasks, a computed route is a tactical graphic that is saved with the scenario and can be used by any simulation object.

          When you create a computed route, you specify rules that VR-Forces should use when creating the route. VR-Forces includes preconfigured rule sets for ships and ground vehicles. You can add additional preconfigured rule sets. You can also add additional rules. The rules and rule sets are configured in ./data/simulationModelSets/<sms>/gui/ computedRouteRulesTypes.xml.


          To create a computed route:

          1. Choose Create Computed Route. The Create Computed Route dialog box opens (Figure 39-2).



            image

            Figure 39-2. Creating a computed route

          2. Optionally, specify a name, label, and overlay.

          3. Select the force for the route.

          4. Click to place the starting point of the route, or enter a value for the Source Loca- tion.

          5. Click to place the end point of the route, or enter a value for the Destination Loca- tion.

          6. Select the type of vehicle from the list. Ground vehicles and ships have a preconfig- ured set of rules. Select Custom to choose a different set of rules.

          7. If you select Custom, select the rules that you want to be enforced for the route. Clear those you do not want to use.

          8. Click Create.


        10. Creating an Intel Collection Area

          Intel collection areas modify the sensor signatures of simulation objects within their boundaries. This affects the ability of other simulation objects to detect them. Intel Collection Areas are created just like other areas. The difference is specification of area modifiers. Area modifiers are set per force. A modifier greater than 1.0 increases the sensor signature for members of that force, making them easier to detect. A modifier less than 1.0 reduces their signature, making them harder to detect.

          To create an intel collection area:

          1. On the Tactical Graphics Palette, select the Intel category.

          2. Click Intel Collection Area.

          3. Draw an area on the map as you would for any other tactical graphic area.

            image

          4. In the Create Intel Collection Area dialog box (Figure 39-3), click the Add button ( ) next to the Area Modifiers label. The Choose Force dialog box opens.


            image

            Figure 39-3. Create Intel Collection Area dialog box

          5. Select the force for which you want to add a modifier.

          6. Click OK. The force gets listed in the Area Modifiers window.

          7. Double-click the Modifier column to make it editable.


          8. Type the modifier value you want to apply to this force.

          9. Optionally, add additional force entries to the list.

          10. Click Create.


        11. Creating Routes for Aircraft

    When you create a route for a fixed-wing entity, remember that as an aircraft flies between the vertices of a route, it starts at the altitude of the first vertex and immedi- ately rises or falls to the altitude of the next vertex as shown in the trajectory in Figure 39-4. (It does not change altitude smoothly between the vertices.) If a terrain feature in- between the two vertices is higher than the trajectory followed by the aircraft, the aircraft will fly into the terrain, even though a line between the two vertices would not pass through the terrain. There is no terrain following built into the route following process for fixed-wing entities.


    image

    Route


    Terrain profile


    Trajectory


    Figure 39-4. Fixed-wing trajectory between vertices

    This caution applies to rotary-wing entities if there are abrupt changes in elevation in the terrain. Rotary-wing entities can follow the terrain, but they only look down, not ahead, so abrupt changes in terrain could cause a crash.

    Creating and Editing Tactical Graphics — Deleting Tactical Graphics

    image

      1. Attaching Tactical Graphics to a Simulation Object

        You can attach tactical graphics to a simulation object so that they move with it. For example, if you draw a route on an aircraft carrier deck, you want the route to stay attached to the deck as the carrier moves. Another example is to attach a Terrain Page-in Area to an aircraft so that it pages in terrain as the aircraft flies.

        You can attach a tactical graphic to an object manually or automatically (3D observer modes only).

        To attach a tactical graphic to a simulation object manually:

        1. Create a tactical graphics as you normally would.

        2. Select the tactical graphic.

        3. Choose Objects Attach Object To. The Attach Object To dialog box opens.

        4. Select the simulation object to which you want to attach the tactical graphic.

        5. Click OK.


    image

        1. Attaching a Tactical Graphic Automatically

          You can attach a tactical graphic to a 3D model as you create it. (This procedure uses the automatic embarkation capability.)

          To attach a tactical graphic to a 3D model when you create it:

          1. Select a 3D observer mode, such as Stealth mode.

          2. Move the observer to view the simulation object on which you want to attach a tactical graphic.

          3. On the Tactical Graphics Palette, select the tactical graphic that you want to create.

          4. Move the cursor over the 3D model you want to attach to until you see a green box.

          5. Click to place the first vertex (or point for point tactical graphics) on the 3D model.

          6. Continue to create the tactical graphic as you normally would. The first point stays anchored to the model.


      1. Deleting Tactical Graphics

        To delete a graphical object:

        1. Select the tactical graphic you want to delete.

        2. Choose Objects Delete, or press the Delete key.


      2. Editing Tactical Graphics

    You can edit a tactical graphic’s properties. The properties that you can edit vary depending on the type of graphic and can include some or all of the following:


    image

    i To edit a tactical graphic, its overlay must be unlocked.

    image


        1. Editing Vertices

          You can edit the vertices of routes and areas. You can edit them dynamically or in the Edit Object dialog box.


          Adding a Vertex

          You can add vertices to a route or area directly on the terrain or in the Edit Object dialog box.

          To add a vertex to a tactical graphic dynamically:

          1. Right-click the vertex next to which you want to add a new vertex. A menu is displayed.

          2. Choose Add Point After or Add Point Before. A point is added midway between the selected vertex and the next or previous vertex, based on the command you chose.

          3. Optionally, edit the new point as described in “Editing a Vertex,” on page 39-14.

            To add a vertex in the Edit Object dialog box:

            1. Select the tactical graphic you want to edit.

            2. Choose Objects Edit. The Edit Object dialog box opens (Figure 39-5).

            3. If Attach Object to Mouse is selected, clear the check box.

            4. In the list of vertices, select the vertex after which you want to add the new vertex.

              image

            5. Click the Add button ( ). A vertex is added midway between the selected vertex and the next vertex. If you selected the last vertex, a new vertex is added to the end of the route.

            6. Optionally, edit the new point as described in “Editing a Vertex,” on page 39-14.

            7. Click Update.



            image

            Figure 39-5. Edit Route dialog box


            Editing a Vertex

            You can edit a vertex dynamically or in the Edit Object dialog box.

            To edit a vertex dynamically:

            1. Double-click the vertex.

            2. Move the mouse to change the vertex’s location.

            3. Use Alt+mouse wheel or Alt+left mouse button+drag to change the altitude.

            4. Click to place the vertex.


              To edit a vertex in the Edit Object dialog box:

              1. Select the tactical graphic you want to edit.

              2. Choose Objects Edit. The Edit Object dialog box opens.

              3. If Attach Object to Mouse is selected, clear the check box.

              4. If you are editing a waypoint, click on the terrain to specify a new location or edit the coordinates and altitude in the Edit Waypoint dialog box.

                If you are editing a phase line, route, or area, you can:

                1. Double-click the coordinate value you want to change to make it editable.

                2. Type a new value and press Enter or click someplace outside of the value.

                  Alternatively, you can click on the map to change the coordinates of the selected vertex. To set the altitude, you must edit the value by hand.

              5. Click Update.


            Deleting a Vertex

            You can delete vertices directly or in the Edit Object dialog box.

            To delete a vertex directly:

            1. Right-click the vertex you want to delete. A menu is displayed.

            2. Choose Delete Point. The point is deleted. (There is no confirmation prompt.)

            To delete a vertex in the Edit Object dialog box:

            1. Select the tactical graphic you want to edit.

            2. Choose Objects Edit. The Edit Object dialog box opens.

            3. If Attach Object to Mouse is selected, clear the check box.

            4. In the list of vertices, select the vertex you want to delete.

              image

            5. Click the Delete button ( ).

            6. Click Update.


        2. Resizing Boxes and Text Objects

          You cannot edit the individual vertices of a box or a text object, you can only resize them.

          To resize a box or text object, double-click one of its vertices to make it editable and drag it to create the new object size.


        3. Rotating an Ellipse

          In addition to changing the width and height of an ellipse, you can rotate it around its center point. You can undo and redo ellipse rotation.

          To rotate an ellipse:

          1. Select the ellipse.

          2. Choose Objects Edit. The Edit object dialog box opens.

          3. Select the Free Rotate check box.

          4. Click OK.

          5. Double-click one of the points on the ellipse to make it editable and drag it in a circular direction.


        4. Changing the Direction of a Line

          All lines have a direction. The direction affects how a simulation object moves along it and the direction that arrows face, if present. If you draw a line and then decide you want to reverse its direction, you can do so.

          To change the direction of a line:

          1. Select the line.

          2. Choose Objects Edit. The Edit object dialog box opens.

            image

          3. Click the Reverse Direction button ( ).

          4. Click OK.


        5. Changing the Color of a Tactical Graphic

          You can change the color of a tactical graphic.

          To change the color of an tactical graphic:

          1. Select the graphic whose color you want to change.

          2. Choose Objects Edit. The Edit object dialog box opens.

          3. Click the Color button image). A color picker dialog box opens.

          4. Click a color button or click the Custom Color button to choose a new color from the Color Picker.

          5. Click OK.


        6. Using the Force Color for Vertices

          You can specify that the vertices of a tactical graphic use the force color. The color is most obvious when the tactical graphic is selected. It is muted when the graphic is not selected.

          To use the force color of a tactical graphics for its vertices:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Tactical Graphics Display Settings page (Figure 41-2).

          3. Select the Color Vertices With Force Color check box.

          4. Click OK.


        7. Changing Linear and Areal Style Properties

          Lines and areas have a variety of properties that you can set in the Edit Style dialog box. The procedure is essentially the same for all of these properties. The properties you might be able to change are as follows:


          image

          First and last segments


          image

          End of all segments


          image Simple image Linear image Main image Simple Reversed

          image Berm


          image

          Last segment


          Figure 39-6. Arrow styles

          To change a style property:

          1. Select the graphic you want to edit.

          2. Choose Objects Edit. The Edit object dialog box opens.

            image

          3. Click the Edit Style button ( ). The Edit Style dialog box opens (Figure 39-7). It lists the style options that you can edit for this tactical graphic.


            image

            Figure 39-7. Edit Style dialog box

          4. Change the properties by selecting options from the appropriate list or typing new values.

          5. Click OK.

    Creating and Editing Tactical Graphics — Active and Inactive Tactical Graphics

    image

      1. Active and Inactive Tactical Graphics

        You can activate (display) and deactivate (hide) all published tactical graphics. You can set a tactical graphic’s state when you create it or edit it, and using a set data request. You can test for a tactical graphic’s state with the Tactical Graphic Active condition. You can set a tactical graphic’s state based on simulation time or time of day.


        image

        i

        i

        In order for inactive tactical graphics to be hidden, you must select Show Only Active Environmentals on the Display Settings dialog box, Tactical Graphics Settings page or click the Show Only Active Tactical Graphics button image)on the Display Settings Toolber.


        image


        In most cases, deactivating a tactical graphic is a GUI effect. The graphic continues to be simulated and published over the network. Simulation objects continue to interact with it. However, if you set an indirect fire event area to be inactive, and you specify that the detonation start time is Wait for Activation, the indirect fire event does not begin until the area is activated.

        For details about the Activation set data request, please see “Activation,” on page 40-3 and “Tactical Graphic Active,” on page 35-14.

        To set the activation state of a tactical graphic:

        1. Select the tactical graphic you want to edit. (If you are creating a new tactical graphic, open the Create object dialog box and skip to step 3.)

        2. Choose Objects Edit. The Edit object dialog box opens.

        3. Click the Set Activation button image). The Set Activation dialog box opens (Figure 39-8).


          image

          Figure 39-8. Set Activation

          Creating and Editing Tactical Graphics — Active and Inactive Tactical Graphics

          image


        4. Select one of the following options from the Activation State list:

          • Active. The tactical graphic is visible.

          • Inactive. The tactical graphic is not visible if Show Only Active Environmentals is selected on the Display Settings dialog box, Tactical Graphics Settings page.

          • Use Activation Times. The tactical graphic is active during the times specified in the dialog box.

        5. If you selected Active or Inactive, click OK. If you selected Use Activation Times:

          1. Select Use Simulation Time or Use Time of Day.

          2. In the Activate At boxes, specify the time you want the tactical graphic to be visible.

          3. In the Deactivate At boxes, specify the time you want the tactical graphic to be hidden.

        6. Click OK.


    image

    40. Setting the State of Tactical Graphics


    You can use set data requests to change the state of a tactical graphic.

    Set Data Requests for Tactical Graphics 40-2

    Activation 40-3

    Allow Crossing 40-4

    Arrowhead Style 40-4

    Color 40-4

    Fill Style 40-5

    Force 40-5

    Line Width 40-5

    Notify Level 40-5

    Pen Style 40-6

    Setting the State of Tactical Graphics — Set Data Requests for Tactical Graphics

    image

      1. Set Data Requests for Tactical Graphics

        Set data requests for tactical graphics provide an alternative to using Edit dialog boxes to change the state of a graphic. The advantage of using set data requests is that you can make changes to tactical graphics from plans and in scripted tasks or scripted sets. You can also quickly make changes from the Set menu without needing to open an Edit dialog box.


        image

      2. Activation

        Setting the State of Tactical Graphics — Activation

        The Activation set data request lets you activate or deactivate tactical graphics. In most cases, this is strictly a visual effect: activated tactical graphics are visible; inactive tactical graphics are not visible. However, if you set an indirect fire event area to be inactive, the indirect fire event does not start until the area is activated.

        Inactive tactical graphics continue to be published and simulation objects interact with them normally. You can use the Tactical Graphic Active condition to test the state of a tactical graphic.

        For more information, please see “Active and Inactive Tactical Graphics,” on page 39-19 and “Tactical Graphic Active,” on page 35-14.

        To activate or deactivate a tactical graphic:

        1. Select the tactical graphic.

        2. Choose Set Disposition Activation. The Activation dialog box opens (Figure 40-1).


          image

          Figure 40-1. Activation

        3. Select one of the following options from the Activation State list:

          • Active. The tactical graphic is visible.

          • Inactive. The tactical graphic is not visible if Show Only Active Environmentals is selected on the Display Settings dialog box, Tactical Graphics Settings page.

          • Use Activation Times. The tactical graphic is active during the times specified in the dialog box.

        4. If you selected Active or Inactive, click OK. If you selected Use Activation Times:

          1. Select Use Simulation Time or Use Time of Day.

          2. In the Activate At boxes, specify the time you want the tactical graphic to be visible.

          3. In the Deactivate At boxes, specify the time you want the tactical graphic to be hidden.

        5. Click OK.

          Setting the State of Tactical Graphics — Allow Crossing

          image

          image

      3. Allow Crossing

        The Allow Crossing set data request allows human entities to walk across a crosswalk. When human characters plan a path that includes a crosswalk, when they arrive at the crosswalk, if crossing is allowed, they can cross the street. If it is not allowed, they stop and wait.

        To set a crosswalk to be enabled or disabled:

        1. Select a crosswalk tactical graphic.

        2. Choose Set Allow Crossing. The Allow Crossing dialog box opens.

        3. Select or clear the Allow Crossing check box.

        4. Click OK.


      4. Arrowhead Style

        The Arrowhead Style set data request lets you set the type of arrowhead, location, and width for linear tactical graphics. For a description of arrowhead styles, please see “Changing Linear and Areal Style Properties,” on page 39-17.

        To set the arrowhead style:

        1. Select a linear tactical graphic.

        2. Choose Set Appearance Arrowhead Style. The Arrowhead Style dialog box opens.

        3. Select an option from the Arrow Style list.

        4. Select an option from the Arrow Placement list.

        5. Specify the width, in pixels, of the arrow.

        6. Click OK.


      5. Color

        The Color set data request lets you change the color of linear and areal tactical graphics.

        To set the color of a linear or areal tactical graphic:

        1. Select a tactical graphic.

        2. Choose Set Appearance Color. The Color dialog box opens.

        3. Select the color you want to use for this tactical graphic.

        4. Click OK.


          image

      6. Fill Style

        Setting the State of Tactical Graphics — Notify Level

        The Fill Style set data request lets you specify the fill for areal tactical graphics. The fill can be horizontal, vertical, or diagonal lines, or various degrees of opacity.

        To set the fill style of an areal tactical graphic:

        1. Select a tactical graphic.

        2. Choose Set Appearance Fill Style. The Fill Style dialog box opens.

        3. Select an option from the Fill Style list.

        4. Click OK.


      7. Force

        You can change the force of a tactical graphic. For details, please see “Force,” on page 34-21.


      8. Line Width

        The Line Width set data request lets you set the width of linear and areal tactical graphics.

        To set the color of a linear or areal tactical graphic:

        1. Select a tactical graphic.

        2. Choose Set Appearance Line Width. The Line Width dialog box opens.

        3. Type a value, in pixels, in the Line Width box.

        4. Click OK.


      9. Notify Level

        You can set the notification level for console messages without opening the Information dialog box. For details, please see “Notify Level,” on page 34-28.

        Setting the State of Tactical Graphics — Pen Style

        image

      10. Pen Style

        The Pen Style set data request lets you specify the type of line used to draw linear and areal tactical graphics. This includes solid lines and varies combinations of dashes and dots.

        To set the pen style of a linear or areal tactical graphics:

        1. Select a tactical graphic.

        2. Choose Set Appearance Pen Style. The Pen Style dialog box opens.

        3. Select an option from the Pen Style list.

        4. Click OK.


    image

    41. Remote Graphics


    Remote graphics are graphics that are drawn onto the scene by remote programs that use the VR-Vantage Remote Draw API. This chapter explains how to display them in VR-Forces.

    Displaying Remote Graphics 41-2

    Viewing a List of Remote Graphics 41-4

      1. Displaying Remote Graphics

        VR-Forces can display graphics sent from other applications using the VR-Vantage Remote Draw API (Figure 41-1).


        image

        Figure 41-1. Remote graphics


        To enable or disable the display of remote graphics:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Tactical Graphics Display Settings page (Figure 41-2).


          image

          Figure 41-2. Tactical Graphics Display Settings page

        3. Select or clear the Show Remote Graphics check box.


    image

    i

    i

    You can also enable and disable remote graphics by choosing Settings

    Remote Graphics.


    image


        1. Viewing a List of Remote Graphics

          Remote graphics can be organized into sets. There is no fixed organization. Labeling of sets is entirely at the discretion of the programmer who develops the application that generates the graphics. The Remote Graphics Panel displays remote graphics in a hier- archy by set.

          The VR-Vantage Remote Draw API lets developers send data about objects as attri- bute:value pairs, for example Speed:30 KM. The attributes are organized by type using attribute group templates. You can enable and disable the display of attribute informa- tion by group and by individual attribute. Figure 41-3 illustrates the attributes for the Entity and Packet attribute group templates displayed in Figure 41-4.


          image

          Figure 41-3. Remote graphics attribute group display


          To view a list of remote graphics:

          1. Choose View Remote Graphics Panel. The Remote Graphics Panel is displayed (Figure 41-4). The Remote Graphics Sets tab lists remote graphics by set.


            image

            Figure 41-4. Remote Graphics Panel

          2. To hide or display a remote graphic set or individual graphic, check or clear its check box in the Remote Graphics Sets list.

          3. To view Attribute Group Templates, select the Attribute Group Templates tab. To see the attribute display, mouse over an object for which display data is available.


    image

  2. Visual and Audio Effects


    VR-Forces has many visual effects that add to your understanding of the interactions between simulation objects. These include fire and detonation lines, sensor contact lines, communications lines, and emitter volumes. You can test for line-of-sight with the intervisibility feature. You can also display many different lighting effects.



    VR-Forces Users Guide


    Section VIII - Visual and Audio Effects


    VIII-1



    Section VIII - Visual and Audio Effects

    VIII-2 VT MAK


    image 42. Displaying Tactical Infor- mation and Effects


    This chapter describes how to manage special visual effects that can be applied to simu- lation objects.


    image

    image

    i

    i

    Many of the effects described in this chapter apply to individual entities in Stealth mode. By default, simulation objects in aggregate-level scenarios do not use 3D models. Therefore, effects such as trailing effects, smoke clouds, and fire and detonation effects are not supported.

    Displaying Trailing and Decal Effects (3D Only) 42-3

    Specifying Models for Trailing Effects and Decal Effects 42-4

    Displaying Track Histories 42-5

    Configuring Track Histories 42-6

    Displaying a Terrain Profile for a Track History 42-7

    Viewing Fire and Detonation Effects 42-8

    Viewing Fire and Detonation Lines 42-9

    Viewing Unit Combat Graphics 42-10

    Visualizing Tasks 42-12

    Pinning Task Visualizations for a Simulation Object 42-13

    Displaying Sensor Contact Lines 42-13

    Enabling the Display of Sensor Contact Lines 42-14

    Specifying which Simulation Objects Display Sensor Contact Lines... 42-14 Configuring Sensor Contact Lines 42-15

    Displaying Laser Designators 42-16

    Displaying Supply Lines 42-17

    Displaying Tactical Smoke 42-17

    image

    Displaying Tactical Information and Effects

    Displaying Electromagnetic Emissions 42-18

    Displaying Radio Communication Lines 42-20

    Enabling Radio Communications Graphics 42-21

    Configuring the Lifetime and Display Mode 42-22

    Configuring the Color of Radio Communication Lines 42-23

    Displaying Tactical Information and Effects — Displaying Trailing and Decal Effects (3D Only)

    image

    image

      1. Displaying Trailing and Decal Effects (3D Only)

        VR-Forces supports trailing effects such as contrails for missiles and aircraft and dust clouds for vehicles. It also supports decal effects, such as tire tracks, footprints, and wakes. In essence, trailing effects are effects that are dispersed through the air, while decal effects are effects that are printed on the ground.

        Trailing effects and decal effects are properties of an observer mode. You can enable and disable them on a per-observer basis.

        Figure 42-1 illustrates some trailing effects.


        image

        Figure 42-1. Tank tracks, dust cloud

        Displaying Tactical Information and Effects — Displaying Trailing and Decal Effects (3D Only)

        image


        To enable or disable trailing effects or decal effects:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Observer Settings page (Figure 42-2).


          image

          Figure 42-2. Display Settings dialog box, Observer Settings

        3. Select or clear the check box for each effect that you want to change.


    42.1.1. Specifying Models for Trailing Effects and Decal Effects

    Trailing effects and decal effects are configured through model definitions. (For the purposes of configuration, trailing effects are categorized as decals.) Each effect must have a model definition that uses a decal schema. Then, in an entity’s entity definition, you configure a visualizer for the effect. For details about creating model definitions, please see “Creating and Editing Model Definitions,” on page 81-9.


      1. Displaying Track Histories

        Track histories allow you to track the paths of simulation objects during an exercise, including the path of munitions as they travel from the shooter to the target. When track histories are enabled, each simulation object leaves a track ribbon. The ribbon is colored based on the simulation object’s force. Figure 42-3 illustrates track histories.



        image image

        3D 2D


        Figure 42-3. Track history

        Track histories are a property of an observer mode. You can enable and disable them on a per-observer basis.


        image

        i

        i

        Track histories have a significant performance and memory cost. For simulations with large simulation object counts, turning track histories off can improve performance and memory usage.


        image


        To enable or disable display of all track histories:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Observer Settings page (Figure 42-2).

        3. Select the observer mode for which you want to change the Track Histories setting.

        4. Select or clear the Track Histories check box.


    image

    image

    i

    i

    You can also enable or disable track histories by choosing Observer Track Histories or clicking the Track Histories button ( ) on the Observer Settings Toolbar.


    image

    Displaying Tactical Information and Effects — Displaying Track Histories

    image

        1. Configuring Track Histories

          You can configure how long track history ribbons are drawn. A track history is composed of a series of segments, joined together to form a line. You can configure how long each segment is and how many segments at a time can be displayed. Drawing shorter segments improves the accuracy of the track history, but can degrade perfor- mance. Increasing the maximum number of segments provides a longer history, but can clutter up the screen if there are many simulation objects and can also affect perfor- mance. Figure 42-4 illustrates the visual result of drastically changing the segment length. The left track history uses the default segment length of 0.5 meters. The right track history has a segment length of 5000 meters.



          image image

          0.5 M segment length 5000 M segment length


          Figure 42-4. Track history segment length

          When a track history reaches the maximum number of segments configured, it starts dropping segments from the beginning of the history (the oldest segments).

          You can specify that track histories have an infinite length. In this case they never drop segments.


          image

          !

          !

          If you specify infinite length for track histories, it is possible that you could eventually use up all the memory in your computer and the program would crash.


          image


          To configure track histories:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Track History Settings page (Figure 42-5).


            image

            Figure 42-5. Track History Settings page

          3. If you want track histories to have an indefinite length, select the Infinite Track check box.

          4. To change the number of segments that can be displayed for a track history, adjust the Track Length slider, or enter a value in the box.

          5. To specify the length of each track history segment, enter a value in the Segment Length box.


        2. Displaying a Terrain Profile for a Track History

          You can display a terrain profile for a track history. (For complete information about terrain profiles, please see Chapter 54, Using Terrain Profiles.)


          image

          i

          i

          The track history terrain profile does not display the track history that gets drawn in the window when you enable track histories. It creates an independent track that starts when you open the terrain profile window.


          image


          To display a terrain profile for a track history:

          1. Select the simulation object whose track history terrain profile you want to see.

          2. Choose Objects Track History Profile. The Terrain Profile dialog box opens. It updates as the simulation object moves.

    Displaying Tactical Information and Effects — Viewing Fire and Detonation Effects

    image

    image

      1. Viewing Fire and Detonation Effects

        VR-Forces can display the following graphic effects when munitions are fired and deto- nated:

      2. Viewing Fire and Detonation Lines

        If fire and detonation lines are enabled, when an entity fires a munition, a line is drawn between the entity and the location of the detonation. The line is colored for the force of the shooter (Figure 42-6).



        image

        3D 2D


        Figure 42-6. Fire line and detonation

        A detonation is identified by a circle with an X through it. The detonation color indi- cates the result of the detonation, as follows:

        • Entity impact – white.

        • Ground impact – gray.

        • Airburst – black.

        • Other – white.

          To enable or disable display of fire and detonation lines, choose Settings Fire / Detonate Lines.

          Displaying Tactical Information and Effects — Viewing Unit Combat Graphics

          image

          image

      3. Viewing Unit Combat Graphics

        When simulation objects in aggregate-level scenarios engage in combat, they display two types of graphics, attack indicators, and attack animations. Attack indicators are triangular areas that show the direction a unit is attacking. They are colored with the force of the attacker. Attack animations show where a simulation object is being attacked. The footprint sector where the attack is taking place blinks from green to white.

        The graphics persist until the attack is over.


        image

        Figure 42-7. Attack indicators

        To enable or disable unit combat graphics:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Unit Display Settings page (Figure 42-8).

          Displaying Tactical Information and Effects — Viewing Unit Combat Graphics

          image


          image

          Figure 42-8. Unit Display Settings page

        3. To enable or disable attack indicators, select or clear the Show Attack Indicators check box.

        4. To enable or disable attack animations, select or clear the Show Attack Animations check box.

        Displaying Tactical Information and Effects — Visualizing Tasks

        image

      4. Visualizing Tasks

    VR-Forces can display graphics that help to show the task a simulation object is executing. Figure 42-9 illustrates task visualization lines in Plan View mode and Stealth mode that show an entity moving to a location.


    image

    i Task visualizations are not available for some tasks.

    image

    You can specify that task be visualized for the selected simulation object. You can also specify that tasks be visualized on a per simulation object basis. The per-simulation object setting is saved as part of the scenario.


    image image

    Figure 42-9. Task visualization

    To specify that the selected simulation object show task visualization lines:

    1. Choose Settings Display. The Display Settings dialog box opens.

    2. Select the Entity Display Settings page (Figure 18-10).

    3. Select the Show Task Visualizations for Selected Entity check box.


      image

      i

      i

      • This setting is valid only if one simulation object is selected. If multiple simulation objects are selected, they do not show visualization lines unless you have pinned them to the simulation object.

        image

      • You can also enable or disable task visualization lines by choosing Observer Task Visualizations or clicking the Task Visualizations button ( ) on the Observer Settings Toolbar.


    image


        1. Pinning Task Visualizations for a Simulation Object

          By default, when task visualizations are enabled, they are only displayed for the selected simulation object. You can pin task visualization to a simulation object so that they are displayed even if it is not selected. This is the only way to have multiple simulation objects visualize their tasks at the same time.

          To pin task visualizations for a simulation object:

          1. Select the simulation object for which you want to visualize tasks.

          2. Choose Objects Pin Task Visualizations.


    42.7. Displaying Sensor Contact Lines

    You can display lines between a simulation object and the objects it detects with its sensors (Figure 42-10). Display of sensor contact lines requires two levels of control. Display of sensor contact lines is an observer-specific setting. They must be enabled in the observer mode to be displayed.

    When display of sensor contact lines is enabled, you can specify that sensor contact lines be shown for specific simulation objects, for the selected simulation object, or for both. If you enable display of sensor contact lines for a specific simulation object, the setting is saved with the scenario.

    You can also configure the width and color of sensor contact lines.


    image

    Figure 42-10. Sensor contact lines

    Displaying Tactical Information and Effects — Displaying Sensor Contact Lines

    image

        1. Enabling the Display of Sensor Contact Lines

          Regardless of other settings, you must enable the display of sensor contact lines in the observer to see them.

          To enable the display of sensor contact lines:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Observer Settings page (Figure 48-2).

          3. In the settings list, select Sensor Contact Lines.


            image

            image

            i

            i

            You can also enable or disable sensor contact lines by choosing Observer Sensor Contact Lines or clicking the Sensor Contact Lines button ( ) on the Observer Settings Toolbar.


            image


        2. Specifying which Simulation Objects Display Sensor Contact Lines

          Assuming that the display of sensor contact lines is enabled, you can specify that partic- ular simulation objects always display them and you can specify that simulation objects display sensor contact lines if they are selected.

          To display sensor contact lines for a simulation object whether it is selected or not:

          1. Select the simulation objects for which you want to enable sensor contact lines.

          2. Choose Objects Pin Sensor Contacts.


            image

            i This setting is saved with the scenario.

            image


            To enable display of sensor contact lines by the selected simulation objects:

            1. Choose Settings Display. The Display Settings dialog box opens.

            2. Select the Sensor Contact Line Settings page (Figure 42-11).


              image

              Figure 42-11. Sensor Contact Settings page

            3. Select or clear Show For Selected.


            image

            i This setting is saved with the GUI settings.

            image

        3. Configuring Sensor Contact Lines

          You can set the color, line width, and arrow size of sensor contact lines.

          To configure sensor contact lines:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Sensor Contact Settings page (Figure 42-11).

          3. Change the values as desired.

    Displaying Tactical Information and Effects — Displaying Laser Designators

    image

    image

      1. Displaying Laser Designators

        You can display laser designation information if it is available. VR-Forces displays a green circle and a range (on top of the entity icon or model) (Figure 42-12).



        image

        3D

        image

        Range


        2D

        Figure 42-12. Laser designators

        To display laser designators, on the Display Settings Toolbar, click the Laser Desig- nator button image).

        Displaying Tactical Information and Effects — Displaying Tactical Smoke

        image

        image

      2. Displaying Supply Lines

        Simulation objects in aggregate-level scenarios can provide supplies to and receive supplies from other simulation objects. When a simulation object is supplying another entity you can display supply lines that show resupply is taking place.

        To display supply lines:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Unit Display Settings page (Figure 42-8).

        3. Select or clear Show Supply Lines.


          image

      3. Displaying Tactical Smoke

        VR-Forces can display tactical smoke munitions fired by VR-Forces entities. You may want to disable tactical smoke if it obscures the observer’s view. Also, if many entities are generating smoke, it could affect performance.


        image

        i

        i

        • Do not confuse tactical smoke and smoke plumes. Smoke plumes are a visual effect displayed when an entity is on fire. Tactical smoke visualizes a smoke munition that affects line-of-sight.

        • If you disable display of tactical smoke, VR-Forces continues to simulate its existence in the back-end and it continues to affect line-of-sight.


        image

        To enable or disable display of tactical smoke, choose Observer Tactical Smoke.

        Displaying Tactical Information and Effects — Displaying Electromagnetic Emissions

        image

      4. Displaying Electromagnetic Emissions

        VR-Forces can display electromagnetic emissions (emitter volumes) for entities that have emitter systems (Figure 42-13). You can configure the colors used to represent emitter frequencies and you can configure the size of the emitter volumes. (For details about configuring emitter volumes, please see “Configuring Emitter Volumes,” on page 84-2.)



        image image

        3D 2D


        Figure 42-13. Emitter volumes

        Display of emitter volumes only affects entities that have emitter systems.

        Displaying Tactical Information and Effects — Displaying Electromagnetic Emissions

        image


        To enable or disable display of electromagnetic emissions:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Entity Display Settings page (Figure 42-14).


          image

          Figure 42-14. Entity Display Settings page

        3. Select or clear the Show Emitter Volumes check box.


          image

          image

          i

          i

          You can also enable or disable emitter volumes by choosing Settings Emitter Volumes, or clicking the Emitter Volumes button ( ) on the Display Settings Toolbar.


          image


      5. Displaying Radio Communication Lines

    VR-Forces can display squawk indicators when a simulation object sends a signal inter- action. It can also display communication lines between simulation objects when a VR- Forces simulation object (or a simulation object in an application built with the appro- priate MAK libraries) sends a radio message to another simulation object. You can configure a communication line’s color and lifetime. Figure 42-15 displays squawk indicators and a line-of-sight communication line.



    image

    Figure 42-15. Radio communication line and squawk indicators

    For communications over large distances, a line-of-sight communication line would travel through the earth. Therefore, you can also display communication lines drawn with the curvature of the earth (Figure 42-16).



    image

    Figure 42-16. Curvature of the earth communication line


        1. Enabling Radio Communications Graphics

          You can globally enable or disable the ability to display radio communication lines. When they are enabled, you can enable and disable communication lines and squawk indicators separately.

          To enable or disable radio communications graphics:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Radio Communications Settings page (Figure 42-17).


            image

            Figure 42-17. Radio Communications Settings page

          3. Select or clear the Show Radio Communications check box.


            image

            i

            i

            You can also enable and disable communication lines by choosing Settings Radio Communication Display or by clicking the Radio Communications button image) on the Display Settings Toolbar.


            image


            To enable or disable communication lines:

            1. Enable radio communication lines.

            2. Select or clear the Show Communication Lines check box.

            To enable or disable squawk indicators:

            1. Enable radio communication lines.

            2. Select or clear the Show Squawk Indicators check box.


        2. Configuring the Lifetime and Display Mode

          You can configure how long a radio communication line is displayed. You can also configure whether it is displayed using line-of-sight or curvature of the earth.

          To configure the lifetime and display mode for radio communication lines:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Radio Communications Settings page (Figure 42-17).

          3. To specify how long a communication line or squawk indicator should be displayed, enter a value, in seconds, in the Communication Line Lifetime and Squawk Indicator Lifetime fields.

          4. To specify the display mode, select an option in the Communication Line Display Mode list.

          5. If you select Curvature of the Earth, adjust the Curved Earth Exaggeration slider to change the degree to which the curvature is exaggerated.


        3. Configuring the Color of Radio Communication Lines

          By default, radio communication lines are green. You can configure communication lines to use force coloring or to be colored based on the frequency of the message.

          When you color by frequency, you specify colors for the frequency ranges you are inter- ested in and a color to use for all messages outside the specified frequencies.

          To configure the color of radio communication lines:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Radio Communications Settings page (Figure 42-17).

          3. To color radio communication lines using the force color, select the Use Force Coloring option.

          4. To color radio communication lines by frequency:

            1. Select the Use Custom Colors option.

              image

            2. Click the Add button ( ). A range is added to the frequency list with a default color (Figure 42-18).


              image

              Figure 42-18. New frequency point

            3. Double-click the starting value of the range to make it editable (Figure 42-19).


              image

              Figure 42-19. Editable frequency point

            4. Type the starting frequency you want to use.

            5. Edit the end frequency.

            6. Double-click the color swatch and select a color for this range.

            7. Optionally, add points for different frequency ranges.

            8. Optionally, click the Outside Range Color color swatch and specify a color for all frequencies not specified in the frequency list.


    image

    i

    i

    If you configure multiple frequency ranges, you cannot add a range whose values are within those of an existing range.


    image


    image

    43. Lighting Effects


    This chapter describes the lighting effects supported by VR-Forces.

    Displaying Lighting Effects 43-2

    Enabling and Disabling Lighting 43-3

    Configuring Ambient and Diffuse Lighting 43-4

    Specifying the Emissive Lighting Scale 43-5

    Displaying Dynamic Lighting 43-6

    Daylight Control of Lights 43-7

    Displaying Ocean Planar Reflections 43-8

    Configuring Ocean Planar Reflections 43-10

    Lens Flare 43-10

    Displaying Crepuscular (Sun) Rays 43-12

    Configuring the Skybox Cube Map 43-14

    Flashlight Mode 43-15

    Using High Dynamic Range Lighting 43-16

    Disabling Lighting and Clouds 43-18

    Displaying Shadows (3D Only) 43-19

    Configuring Shadows 43-21

    Lighting Effects — Displaying Lighting Effects

    image

      1. Displaying Lighting Effects

        VR-Forces can simulate a variety of lighting effects, including:

        • Dynamic lighting

        • Ocean planar reflection

        • Lens flare

        • Crepuscular (sun) rays.

        • Shadows.

          Use of lighting effects affects performance. VR-Forces lets you enable and disable some effects so you can adjust the mixture of performance and effects that best meets your needs.


      2. Enabling and Disabling Lighting

    When lighting is enabled, VR-Forces takes into account direct and ambient lighting when it renders a scene. During the daytime, objects are brightly lit. At night, you cannot see them unless an object is casting light on them or you use a sensor mode that provides night vision.

    If lighting is disabled you can see objects regardless of the time of day. Lighting may not be realistic.

    To enable or disable lighting:

    1. Choose Settings Display. The Display Settings dialog box opens.

    2. Select the Lighting Render Settings page (Figure 43-1).


      image

      Figure 43-1. Lighting Render Settings

    3. Select or clear the Enable Lighting check box.

    Lighting Effects — Enabling and Disabling Lighting

    image

        1. Configuring Ambient and Diffuse Lighting

          Ambient lighting is the lighting available to objects that are not in a direct form of light, such as sunlight. Diffuse lighting is light that is reflected off an object. You can adjust the overall amount of ambient and diffuse lighting in the scene and you can configure whether objects use the material ambient and diffuse values specified in their models or use values provided by VR-Forces.


          Configuring the Ambient and Diffuse Scale Values for Scene Lighting

          You can set a scale factor for ambient and diffuse light that is present in the scene. Lower values make objects darker. Higher values make them lighter. The ambient or diffuse scale factor is independent of how material ambient and diffuse values are set.

          To specify the ambient and diffuse lighting scale values:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Lighting Render Settings page (Figure 43-1).

          3. Adjust the Diffuse Scale slider or change the value in the box.

          4. Adjust the Ambient Scale slider or change the value in the box.


            Configuring the Material Ambient and Diffuse Values for Materials

            Polygons in a 3D scene have a material and a texture. Polygon materials may specify specular, diffuse, and ambient colors that define the way they respond to incoming light.

            The ambient color specifies the color used when it is in indirect light. Sometimes the ambient values for different objects do not work well together. You can specify that objects use the ambient material value, or let VR-Forces globally specify ambient mate- rial values.

            In addition to specifying which material ambient and diffuse values to use, you can set a scale factor. Lower values make objects darker. Higher values make them lighter. The material ambient or diffuse scale factor is independent of how ambient and diffuse values are set for scene lighting.

            To configure the material ambient value:

            1. Choose Settings Display. The Display Settings dialog box opens.

            2. Select the Lighting Render Settings page (Figure 43-1).

            3. To use the ambient values specified by objects, clear the Use Global Ambient Value check box. To have VR-Forces use a global value, select the Use Global Ambient Value check box.

            4. If you selected the Use Global Ambient Value check box, optionally, adjust the Global Ambient Value slider or change the value in the box.


              To configure the material diffuse value:

              1. Choose Settings Display. The Display Settings dialog box opens.

              2. Select the Lighting Render Settings page (Figure 43-1).

              3. To use the diffuse values specified by objects, clear the Use Global Diffuse Value check box. To have VR-Forces use a global value, select the Use Global Diffuse Value check box.

              4. If you selected the Use Global Diffuse Value check box, optionally, adjust the Global Diffuse Value slider or change the value in the box.


        2. Specifying the Emissive Lighting Scale

          You can change a scale value that controls the brightness of emissive textures. This allows you to make windows, street lights, and other emissive light sources darker or brighter. Increasing the scale value increases the brightness.

          To specify the emissive lighting scale value:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Lighting Render Settings page (Figure 43-1).

          3. Adjust the Emission Scale slider or change the value in the box.

    Lighting Effects — Displaying Dynamic Lighting

    image

      1. Displaying Dynamic Lighting

        VR-Forces can display light cast by light sources such as headlights, street lamps, and spotlights. Display of dynamic lighting is an observer-specific feature. It is disabled by default.

        Dynamic lights are either part of the terrain or part of an entity model. If they are part of an entity model, they can be set permanently on or they can be turned on and off by the appearance bit. VR-Forces entities that have lights can enable them using the Set Appearance set data request.

        Figure 43-2 shows a night-time scene with dynamic lighting enabled. The HMMWV’s taillights cast light to the rear. The headlights cast light forward. Street lamps and windows are also casting light.



        image

        Figure 43-2. Dynamic Lighting enabled


        image

        i

        i

        • Light points that are part of the terrain, such as runway lights, automati- cally turn on at dusk and turn off at dawn.

        • Emissive lights, such as automobile headlights, are always on. You cannot change these lighting settings.

          image

          Lighting Effects — Displaying Dynamic Lighting

          image


          To enable dynamic lighting,

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Observer Settings page.

          3. In the list of settings, select Dynamic Lights.


          image

          i

          i

          You can also enable or disable dynamic lighting by choosing Observer

          Dynamic Lights.


          image


              1. Daylight Control of Lights

                Some types of lights turn on and off automatically based on the time of day. Light points:

                • Light points in an OpenFlight file that has been loaded as a terrain patch are auto- matically discovered and placed under daylight control.

                • Light points in an earth file that are created with model statements that have a feature name registered with the lightPointInstaller module in ../appData/import- Config/registrant_feature_list.csv (default is “lights”) are placed under daylight control. The following example shows earth file syntax:

                  <model name="alamoana-lights" driver="feature_geom" >

                  <features name="lights" driver="ogr">

                  <url>../../data/Terrain/Hawaii/Features/InfrastructureP.shp</url>

                  </features>

                • Light points in an OpenFlight file that has been loaded as an articulated model use the daylightControlledLights model definition parameter.

                • S57 navigation lights use the EXCLIT attribute found in the S57 data for each light.

                • Lights placed when creating procedural airports use standard model definitions. For example, the PAPI lights use the LightPAPILeft and LightPAPIRight model definitions. The daylightControlledLights parameter determines whether these lights are under daylight control.

          Light sources (lights that cast light onto other objects) are discovered on the cull pass of the scene graph. Sources found under the terrain root or props root of the scene graph are automatically put under daylight control.

          Lighting Effects — Displaying Ocean Planar Reflections

          image

      2. Displaying Ocean Planar Reflections

    VR-Forces can show the reflection of terrain and objects on water (Figure 43-3). To see planar reflections, dynamic ocean must be enabled. (For details about enabling dynamic ocean, please see “Enabling Marine Effects,” on page 11-17.)

    Displaying ocean planar reflections degrades performance.



    image

    Figure 43-3. Ocean planar reflection

    Lighting Effects — Displaying Ocean Planar Reflections

    image


    To enable or disable planar reflections:

    1. Choose Settings Display. The Display Settings dialog box opens.

    2. Select the Ocean Settings page (Figure 43-4).


      image

      Figure 43-4. Ocean Settings

    3. Select or clear the Enable Ocean Planar Reflections check box.

    Lighting Effects — Lens Flare

    image

        1. Configuring Ocean Planar Reflections

          To reduce the performance impact of ocean planar reflections, you can configure the LOD scale. The LOD scale affects the distance from the observer at which VR-Forces switches LODs. The higher the value, the more quickly LODs are switched.

          The Texture Height and Texture Width parameters affect the resolution of the ocean planar reflection texture, in pixels. Higher resolution decreases performance.

          To configure ocean planar reflections:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Ocean Settings page (Figure 43-4).

          3. To change the ocean planar reflection LOD scale, adjust the LOD Scale slider under Enable Ocean Planar Reflections, or change the value in the box.

          4. To change the width or height of the ocean planar reflection texture, adjust the Texture Width or Texture Height slider under Enable Ocean Planar Reflections, or change the values in the boxes.


      1. Lens Flare

        Lens flare is a visual artifact often seen when looking at light sources such as the sun through a camera lens (Figure 43-5). VR-Forces can simulate lens flare when the observer looks towards the sun.



        image

        Figure 43-5. Lens flare

        Lighting Effects — Lens Flare

        image


        image

        i Lens flare is supported only when high dynamic range lighting is enabled.

        image

        To enable or disable lens flare:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the High Dynamic Range Settings page (Figure 43-6).


          image

          Figure 43-6. High Dynamic Range Settings page

        3. Select or clear the Enable Lens Flare check box.

          Lighting Effects — Displaying Crepuscular (Sun) Rays

          image

      2. Displaying Crepuscular (Sun) Rays

        VR-Forces can simulate the effect of crepuscular rays (sunbeams) beaming through clouds (Figure 43-7).



        image

        Figure 43-7. Crepuscular rays

        Lighting Effects — Displaying Crepuscular (Sun) Rays

        image


        To enable or disable crepuscular (sun) rays:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Render Settings page (Figure 43-8).


          image

          Figure 43-8. Render Settings page

        3. Select or clear the Enable Crepuscular Rays (Sun Rays) check box.

          Lighting Effects — Configuring the Skybox Cube Map

          image

      3. Configuring the Skybox Cube Map

        A skybox cube map is a graphics technique used to render reflections and sky effects. The skybox cube map is rendered from the location of the observer. As the observer moves, the cube map needs to be recalculated, which is computationally expensive.

        VR-Forces lets you configure the distance that the observer has to move (the skybox cube map regeneration threshold) before it recalculates the cube map. Increasing the threshold can improve performance, at the cost of visual quality.

        You can also choose to omit clouds in the skybox cube map. Omitting clouds can increase performance.

        To configure the skybox cube map:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Ocean Settings page (Figure 43-4).

        3. Adjust the Skybox Cube Map Regeneration Threshold slider or enter a value in the box.

        4. Optionally, select the Omit Clouds in Cube Map check box.


          image

      4. Flashlight Mode

        Lighting Effects — Flashlight Mode

        VR-Forces can light a circular area as if the observer is using a flashlight. You can move the flashlight beam and increase or decrease the diameter of the flashlight beam.



        image

        Figure 43-9. Flashlight mode

        To turn flashlight mode on or off, press f.

        To move the flashlight beam, hold down Alt and the right mouse button and move the mouse.

        To change the size of the flashlight beam, hold down Alt and move the mouse scroll wheel forward or back.

        Lighting Effects — Using High Dynamic Range Lighting

        image

      5. Using High Dynamic Range Lighting

        High dynamic range (HDR) lighting makes scenes look more realistic. They look particularly good on HDR monitors. HDR is enabled by default.

        To configure HDR lighting:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the High Dynamic Range Settings page (Figure 43-6).

        3. To enable or disable HDR lighting, select or clear the Enable HDR check box.

        4. Enable other settings as desired.

        5. For those settings that are enabled, adjust their parameters. Table 43-1 describes the HDR settings.

          image

          Table 43-1: HDR settings


          Setting Description

          Setting Description

          Enable HDR Turn High Dynamic Range (HDR) on/off. When HDR is turned on the scene is rendered in full 16-bits per color floating point and then tone mapped to 8-bits per color before being sent to the display. Additionally, there are post process effects applied to objects that are greater than the display range.

          Enable Auto Exposure

          Turn on/off auto exposure, which is a post process that scales the intensity of the rendered image based on the intensity of the screen. When auto exposure is turned off the global lighting values are used to scale the intensity to a reasonable value.

          Enable Bloom Turn on/off the bloom post process effect. This effect is a blur- ring of high intensity objects in the scene which gives a glow around bright objects like light points.

          Enable Streaks Turn on/off the streak post process effect. This effect creates a star effect by streaking the high intensity objects in all direc- tions.

          Enable Lens Flare Turn on/off the lens flare post process effect. This effect creates a lens flare effect for high intensity objects.

          Light Point Scale When HDR is turned on, light point intensity is scaled by this setting.

          Dynamic Light Scale

          Emissive Texture Scale

          When HDR is turned on, the intensity of dynamic lights are scaled by this setting.

          When HDR is turned on, the intensity of the emissive textures are scaled by this setting.

          Specular Scale When HDR is turned on the lighting specular component is scaled by this setting.

          image

          Lighting Effects — Using High Dynamic Range Lighting

          image


          image

          Table 43-1: HDR settings


          Setting Description

          Setting Description

          Shininess Scale When HDR is turned on the lighting shininess component is scaled by this setting. Exposure adjustments are all related to how the intensity of the scene is scaled before being tone mapped. These values are in order based on when they are applied to the scalar.

          Rate Scale When Auto Exposure is enabled, this scales the time it takes for the auto exposure to adjust to changes in the scene. Increase this value to reduce the time it takes for the auto exposure to adjust.

          Pre Scale When Auto Exposure is enabled, this scales the calculated inten- sity for the scene. Increase this value to reduce the overall inten- sity of the final image.

          Min Difference When Auto Exposure is enabled, this clamps the minimum value of the calculated intensity to a portion of the global lighting value. This is used to prevent the auto exposure from going too low compared to the global lighting value.

          Max Difference When Auto Exposure is enabled, this clamps the maximum value of the calculated intensity to a portion of the global lighting value. This is used to prevent the auto exposure from going too high compared to the global lighting value.

          Post Scale Scales the scalar after all Auto Exposure calculations have been done. This also affects the global lighting value when Auto Exposure is turned off. Increase this value to reduce the overall intensity of the final image.

          Final Clamp Min Minimum value for the final value that will be used to scale the intensity prior to tone mapping.

          Final Clamp Min Maximum value the final value that will be used to scale the intensity prior to tone mapping.

          Bloom Scale Scales the bloom before it is applied to the scene. Increase this value to increase the intensity of the bloom effect on high inten- sity objects.

          Streak Intensity Scale


          Number of Streaks

          Streak Length Scale

          Streak Rotation Offset

          Scales the streaks before they are applied to the scene. Increase this value to increase the intensity of the streak effect on high intensity objects.

          Number of streaks that the streak effect will create for each high intensity object. Maximum of 8 streaks.

          Scales the length of the streak effect. Increase this value to increase the length of the streak effect.

          Rotates the streak effect so that it changes the direction that the streaks point.


          image

          Lighting Effects — Disabling Lighting and Clouds

          image


          image

          Table 43-1: HDR settings


          Setting Description

          Setting Description

          Lens Flare Scale Scales the lens flare effect before it is applied to the scene. Increase this value to increase the intensity of the lens flare effect.

          Gamma Final color correction used to adjust the image based on the display. Change this value based on the characteristics of the display being used.

          image


      6. Disabling Lighting and Clouds

        When you are using XR observer mode and you move the observer out from the terrain, the lighting and cloud effects can interfere with your ability to view simulation objects. Therefore, VR-Forces lets you quickly disable lighting effects and clouds. By default, they are enabled in Stealth observer mode and disabled in XR observer mode.

        To enable or disable lighting and clouds, choose Observer Sky.


      7. Displaying Shadows (3D Only)

    VR-Forces can display shadows for entities, props, and terrain features.



    image

    Figure 43-10. Shadows

    You can enable and disable shadows and you can configure shadow quality.


    image

    i Enabling shadows can affect performance.

    image


    To enable and disable shadows globally:

    1. Choose Settings Display. The Display Settings dialog box opens.

    2. Select the Shadow Settings page (Figure 43-11).


      image


      Figure 43-11. Display Settings, Shadow Settings page

    3. Select or clear the Enable Shadows check box.


    image

    i You can also enable and disable shadows by choosing Settings Shadows.

    image


        1. Configuring Shadows

          You can configure which objects cast shadows and parameters that affect performance and the quality of shadows. Shadow parameters include the following:

          • Cascades. A scene is split into sections, with those closest to the camera showing the highest resolution shadows. You can configure the number of splits and how the quality of resolution changes as you move away from the camera.

          • Polygon offset. These settings shift shadows to minimize Z-fighting.

          • Shadow ambient factor. Hides Z-fighting and other visual artifacts.

          • Shadow stability. Affects resolution when the camera moves.

          • Filtering. These options affect visual quality.

          • Sample Distribution Shadow Maps (SDSM). SDSM increases rendering quality at the expense of performance.

    To configure how shadows are rendered:

    1. Choose Settings Display. The Display Settings dialog box opens.

    2. Select the Shadow Settings page (Figure 43-11).

    3. To enable or disable shadows for object types, select or clear the Entities Cast Shadows, Props Cast Shadows, or Terrain Casts Shadows check boxes.

    4. Change other parameters as desired.


    image

    44. Marine Effects


    This chapter describes different marine effects and water droplets.

    Displaying Water Droplets and Splash Effects 44-2

    Enabling Sea Spray 44-4

    Setting the Size of Water Droplets 44-5

    Enabling High Quality Rotor Wash 44-5

    Displaying Wakes and Spray Effects 44-6

    Enabling Buoyancy for Surface Entities 44-7

      1. Displaying Water Droplets and Splash Effects

        When it is raining, VR-Forces can simulate raindrops hitting the observer’s camera lens (Figure 44-1). If the observer is close to the surface of the ocean (as if a periscope were being raised or lowered), VR-Forces can simulate the effect of waves and water droplets splashing on the observer’s camera.



        image

        Figure 44-1. Rain effect

        When dynamic ocean is enabled, VR-Forces can simulate sea spray (most visible in high seas) (Figure 44-2). It can also display rotor wash for hovering helicopters. You can display rotor wash at two levels of quality.



        image

        Figure 44-2. Sea spray effects


        You can change the size of the water droplets for splash effects and sea spray. For details, please see “Setting the Size of Water Droplets,” on page 44-5.

        To enable or disable splash effects:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Observer Settings page (Figure 44-3).


          image

          Figure 44-3. Observer Settings page

        3. Select or clear the Rain Splash, Wave Splash, or Ocean Spray effect check boxes.


        1. Enabling Sea Spray

          To enable sea spray effects:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Ocean Settings page (Figure 44-4).


            image

            Figure 44-4. Ocean Settings page

          3. Select Enable Sea Spray Particle Effects.


        2. Setting the Size of Water Droplets

          You can change the size of water droplets for splash effects and sea spray.

          To change the size of water droplets:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Render Settings page (Figure 44-5).


            image

            Figure 44-5. Render Settings page

          3. Adjust the Water Droplets Size slider or enter a value in the box.


        3. Enabling High Quality Rotor Wash

          To enable high quality rotor wash:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Ocean Settings page (Figure 44-4).

          3. Select Enable High Quality Rotor Wash.

    Marine Effects — Displaying Wakes and Spray Effects

    image

    image

      1. Displaying Wakes and Spray Effects

        When dynamic ocean is enabled, surface entities display wakes and spray effects. However, these effects affect performance. You can disable them if you need to empha- size performance over visual effects.

        Wakes have their own schema, with many attributes, including length, offset, the amount of time over which they fade out, and LOD distance. You can edit these attri- butes for individual entities in the Visual Model Editors dialog box.

        To enable or disable wakes and spray effects:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Entity Display Settings page (Figure 44-6).


          image

          Figure 44-6. Entity Display Settings page

        3. To enable or disable wakes, select or clear the Enable Wakes on Dynamic Oceans check box.

        4. If wakes are enabled, select Enable Spray Effects on Surface Vehicles to enable spray effects. Clear the check box to disable them. Disabling wakes also disables spray effects.

          Marine Effects — Enabling Buoyancy for Surface Entities

          image

          image

          image

      2. Enabling Buoyancy for Surface Entities

        When dynamic ocean is enabled, surface entities can bob up and down with

        wave action. However, the buoyancy models affect performance. You can disable buoy- ancy if you need to emphasize performance over visual effects. You can also control the area in which buoyancy models are calculated.

        If buoyancy is enabled, VR-Forces calculates buoyancy only for models within certain distances of the observer, as follows:


        image

        i

        i

        VR-Forces uses the nearer of the far clipping plane or the maximum buoyancy LOD range to determine the distance at which it stops calculating buoyancy models.


        image

        Marine Effects — Enabling Buoyancy for Surface Entities

        image


        When buoyancy is enabled, you can specify that VR-Forces use face front culling. VR- Forces calculates buoyancy models for all entities within the minimum range and all entities between the near clipping plane and the far clipping plane or maximum buoy- ancy LOD range, whichever is closest. In Figure 44-7, the shaded area is the area in which buoyancy models are calculated.


        far clipping plane or maximum LOD distance


        near clipping plane


        near clipping plane


        image

        minimum range

        Observer


        Figure 44-7. Face front culling

        By default, face front culling is disabled and only distance culling is used.

        To enable or disable the buoyancy models:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Entity Display Settings page (Figure 44-6).

        3. Select or clear the Enable Buoyancy Models for Surface Vehicles check box.

        4. To specify the distance beyond which buoyancy models are not calculated, adjust the Default LOD Distance slider or change the value in the box. (If the default distance is set to 0, then entities that do not have an LOD range set in their model definitions will have an infinite buoyancy range. However, buoyancy will not be calculated past the far clipping plane.)

        5. To specify the radius within which all entities have their buoyancy models calcu- lated, adjust the Minimum Cull Distance slider or change the value in the box.

        6. Optionally, specify use of face front culling.


    image

    45. Using Sensors


    This chapter explains how to enable and configure simulated night-vision goggle (NVG) and infrared views of the scene.

    Using Sensors 45-2

    Enabling Sensors 45-3

    Configuring Sensors 45-4

    Adding New Sensors 45-5

    Using Sensors — Using Sensors

    image

      1. Using Sensors

        VR-Forces can simulate the way that the 3D scene would look if an observer were using visual sensor devices such as night vision goggles or viewing the infrared spectrum. This is an observer-specific setting. You can adjust the contrast, blur, and noise of the view.

        VR-Forces includes one sensor module – CameraFX, which uses the SenSim libraries from JRM Technologies. The sensors do not take into account the materials of the objects that you are viewing. They simply filter the view to produce the desired effect.



        image

        No sensor (daylight) IR sensor


        Figure 45-1. CameraFX


        image

        i

        i

        The sensors described in this chapter are strictly visual effects. They have no relationship to the sensor systems used by simulation objects.


        image


        image

      2. Enabling Sensors

        Using Sensors — Enabling Sensors

        Sensors are observer-specific (Figure 45-2). VR-Forces includes observer modes that have sensors enabled. The names of the observer modes match the sensor modes that they enable.

      3. Configuring Sensors

        You can configure the following aspects of sensors:

      4. Adding New Sensors

    You can add, rename, and delete sensors.

    To add a sensor:

    1. Choose Settings Display. The Display Settings dialog box opens.

    2. Select the Sensor Settings page (Figure 45-3).

      image

      image

    3. On the Sensor Mode line, click the Add button ( ). A new sensor called sensor_number is added. There are no configuration options on the page. (To rename the sensor, click the Rename button ( ) and enter a new name.)

    4. In the Sensor Module list, select CameraFX. The available configuration options are added to the page.

    5. Select the type of sensor that you want this to be (Full Color, Monochrome, Infrared, or NVG).

    6. Set the Blur, Noise, and Gain levels.

    Using Sensors — Adding New Sensors

    image


    image 46. Intervisibility


    This chapter explains how to use the intervisibility feature.

    Intervisibility (Line-of-Sight) 46-2

    Types of Intervisibility 46-3

    Point-to-Point Intervisibility 46-3

    Intervisibility Fan 46-4

    Entity Intervisibility 46-4

    Intervisibility Objects can be Transient or Permanent 46-5

    Creating a Transient Intervisibility Object 46-6

    Creating a Permanent Intervisibility Object 46-7

    Editing an Intervisibility Object 46-8

    Configuring Intervisibility Lines and Fans 46-9

    Pinning an Intervisibility Object to a Simulation Object 46-10

    Showing and Hiding Intervisibility Lines 46-10

    Displaying Intervisibility Line Information 46-11

    Displaying an Intervisibility Line’s Terrain Profile 46-12

    Deleting Intervisibility Objects 46-12

    Intervisibility — Intervisibility (Line-of-Sight)

    image

      1. Intervisibility (Line-of-Sight)

        You can display intervisibility (line-of-sight or LOS) between points, within areas, and between a point and all simulation objects in a defined area. Intervisibility displays can be transient or permanent. Permanent intervisibility displays are objects. You can resize them and move them around the terrain. Intervisibility objects can be tied to a partic- ular simulation object.

        You can display a terrain profile for point-to-point intervisibility lines.


        image

        Tanks can see each other


        image


        Tanks cannot see each other


        Figure 46-1. Intervisibility

        You can configure parameters for intervisibility objects, such as the height above the terrain from which intervisibility is calculated. You can also change the colors used to display intervisibility.


        image

        i

        i

        • By default, intervisibility between simulation objects is calculated from the center of their bounding volumes. The VR-Forces target detection sensor uses an offset, which is often above the center of the entity. Unless you change the Origin LOS Elevation value in the Intervisibility Options dialog box to use the same offset as the target detection sensor, simula- tion objects may shoot at targets for which they do not appear to have line-of-sight.

        • Linear and areal features do not block line-of-sight. Only point features block LOS.


          image


          image

      2. Types of Intervisibility

        Intervisibility — Types of Intervisibility

        VR-Forces supports the following types of intervisibility:

        • Point-to-point (intervisibility line).

        • Intervisibility fan.

        • Entity intervisibility.

    The intervisibility fan and entity intervisibility are displayed as a circular area. However, intervisibility calculations are made within a cylindrical area extending above and below the terrain, so that intervisibility calculations can be made for air platform entities and subsurface entities.

    In the 2D view, intervisibility lines are fully visible on the terrain. In the 3D view, they may pass through the terrain.


        1. Point-to-Point Intervisibility

          Point-to-point intervisibility (Figure 46-2) shows the line-of-sight between any two points. The portion of the line that is visible from the starting point is green. The portion that is not visible is red. You can change the colors used.



          image image

          2D 3D


          Figure 46-2. Point-to-point intervisibility

          Intervisibility — Types of Intervisibility

          image

        2. Intervisibility Fan

          An intervisibility fan (Figure 46-3) shows a series of lines radiating from the center of a circle to its outer edge. Each ray shows intervisibility along its path from the origin to the border. You can configure the distance between rays. (For details, please see “Configuring Intervisibility Lines and Fans,” on page 46-9.)



          image image

          2D 3D


          Figure 46-3. Intervisibility fan


        3. Entity Intervisibility

    Entity intervisibility (Figure 46-4) shows which simulation objects are visible from the center of a defined area and whether or not the simulation objects can see the center point. If you center the intervisibility circle on a point on the terrain, you can see which simulation objects can see that point. If you lock the circle to a simulation object, you can see which simulation objects can see that object and which it can see. (For details, please see “Configuring Intervisibility Lines and Fans,” on page 46-9.)


    image image

    2D 3D

    Figure 46-4. Entity intervisibility


    46.3. Intervisibility Objects can be Transient or Permanent

    You can configure intervisibility objects to be transient or permanent. (For details, please see “Configuring Intervisibility Lines and Fans,” on page 46-9.) A transient intervisibility object displays intervisibility from the origin point (defined by a mouse click) to wherever you move the cursor. If you click the mouse again, you reset the origin. You cannot use the mouse for other actions until you exit intervisibility mode (by right-clicking). This mode is convenient when you want to quickly check intervisi- bility, but do not want to keep intervisibility objects in the display.

    A permanent intervisibility object stays in the display after you create it. You can resize the object, edit drawing options, and move it around the display. Intervisibility objects are not saved as part of the scenario.

    Intervisibility — Intervisibility Objects can be Transient or Permanent

    image

        1. Creating a Transient Intervisibility Object

          Transient intervisibility objects do not stay in the display after you quit intervisibility mode.

          To display transient intervisibility:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Intervisibility Settings page (Figure 46-5).


            image

            Figure 46-5. Intervisibility Settings page

          3. Clear the Left Click Makes Objects Permanent check box.

          4. Choose Intervisibility Create intervisibility_type, where intervisibility_type is a type of intervisibility object, or click one of the buttons on the Intervisibility Toolbar.

          5. Click on the terrain to place the origin of the intervisibility object.

          6. Move the cursor around the terrain to expand and contract the object. For point- to-point intervisibility, moving the cursor also changes the direction of the line.

          7. To change the origin of the intervisibility display, click another location on the terrain.

          8. Right-click to cancel intervisibility mode.


        2. Creating a Permanent Intervisibility Object

          Permanent intervisibility objects remain in the display after you create them. (However, they are not saved as part of the scenario.)

          To create a permanent intervisibility object:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Intervisibility Settings page (Figure 46-5).

          3. Select Enable Intervisibility Objects.

          4. Select Left Click Makes Objects Permanent.

          5. Choose Intervisibility Create intervisibility_type, where intervisibility_type is a type of intervisibility object, or click one of the buttons on the Intervisibility Toolbar.

          6. Click on a simulation object or on a location on the terrain where you want the origin of the intervisibility object to be located. An intervisibility object is displayed. As you move the cursor closer to the origin, or farther away from it, the circle or line contracts and expands. If you are displaying point-to-point, you can rotate the line around the origin before you specify the end point.

          7. Click on the terrain where you want to fix the end point of a line or border of a circle.

    Intervisibility — Editing an Intervisibility Object

    image

      1. Editing an Intervisibility Object

        You can change the following aspects of an intervisibility object:

        • The location of either end point of an intervisibility line, to change its length and direction.

        • The origin of an intervisibility fan, thereby moving the entire fan.

        • The diameter of an intervisibility fan.


          image

          i

          i

          If an intervisibility object is anchored to a simulation object, you cannot change the origin.


          image


          To change the length or diameter of an intervisibility object:

          1. To edit a line, double-click its end point.

            To edit a fan, select the object, then double-click the outer ring of the fan. The cursor changes image).

          2. Drag the end point or circle towards or away from the origin. If you are editing an intervisibility line, you can move the end point to any location.

          3. Click to exit edit mode.


          image

          i

          i

          To revert to the original size of the intervisibility object, right-click while you are still in edit mode.


          image


          To move an intervisibility fan or line:

          1. Double-click a fan’s center point or any place on a line. The cursor changes.

          2. Drag the object to a new location.

          3. Click to set the location.


          image

          i

          i

          To revert to the original location of the intervisibility object, right-click while you are still in edit mode.


          image

          Intervisibility — Configuring Intervisibility Lines and Fans

          image

      2. Configuring Intervisibility Lines and Fans

        You can configure the following attributes of intervisibility objects:

        • The elevation of the origin and end point.

        • The sampling rate for intervisibility fans.

        • The update rate for entity intervisibility fans.

        • Display of height above terrain lines (3D) and height labels (3D and 2D).

        • The colors used to display intervisibility objects.

        • Display of range and bearing labels. For more information about range and bearing labels, please see “Displaying Intervisibility Line Information,” on page 46-11.

          When you change colors or the sampling rate, changes affect all existing intervisibility objects. Changes to the origin and end point elevation only affect newly created objects.

          To configure intervisibility objects:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Intervisibility Settings page (Figure 46-5).

          3. Change the settings as desired. Table 46-1 describes the settings.

          image

          Table 46-1: Intervisibility settings


          Option Description

          Option Description

          Enable Height Above Terrain Lines

          Show Height Above Terrain Lines Only for Selected

          Enables or disables display of height above terrain lines (3D) and height labels (3D and 2D).

          If selected, HAT lines are displayed only for the selected intervisibility objects.

          Object Origin Elevation The height, in meters, above the terrain at the origin

          point from which to calculate intervisibility.

          Object End Point Eleva- tion

          The height, in meters, above the terrain at the end point to use to calculate intervisibility.

          Fan Line Sample Interval The distance, in degrees, between each ray in a intervisi-

          bility fan. After changing this value, press Enter or click away from the field.

          Entity Fan Update Interval How frequently, in seconds, to update the entity intervis-

          ibility fan.

          Visible Color Blocked Color

          The colors to use for the portion of an intervisibility line that a simulation object can see and the portion where visibility is blocked.

          Circle Color The color to use for the outer circle of an intervisibility fan.

          Show Range and Bearing Labels

          Enable or disable display of range and bearing labels.


          image

          Intervisibility — Pinning an Intervisibility Object to a Simulation Object

          image


          image

          Table 46-1: Intervisibility settings


          Option Description

          Option Description

          Background Color Specify the background color for range and bearing

          labels.

          Background Opacity Specify the opacity of the background for range and

          bearing labels.

          Show Location Field If range and bearing labels are displayed, show the loca-

          tion of the endpoints.

          Show Change in Altitude Field

          If range and bearing labels are displayed, show the differ- ence in altitude between the endpoints.

          Show Heading Field If range and bearing labels are displayed, show the

          heading of each endpoint relative to the other point.

          Show Range Field If range and bearing labels are displayed, show the length

          of the intervisibility line.

          image


      3. Pinning an Intervisibility Object to a Simulation Object

        When you pin an intervisibility object to a simulation object, the intervisibility object moves with the simulation object and you know that its origin is centered on the simu- lation object.

        To pin an intervisibility object to a simulation object:

        1. Select the simulation object to which you want to pin the intervisibility object.

        2. Choose Intervisibility Create intervisibility_type, where intervisibility_type is a type of intervisibility object, or click one of the buttons on the Intervisibility Toolbar. The origin is placed on the simulation object icon or model.

        3. Specify the end point for the intervisibility object.


      4. Showing and Hiding Intervisibility Lines

        You can toggle the display of intervisibility lines on and off.

        To enable or disable the display of intervisibility lines:

        1. Choose Settings Display. The Display Settings dialog box opens.

        2. Select the Intervisibility Settings page (Figure 46-5).

        3. Select or clear the Enable Intervisibility Objects check box.


        image

        image

        i

        i

        You can also enable and disable display of intervisibility objects by choosing Intervisibility Enable/Disable Intervisibility, or by clicking the Enable/Disable Intervisibility button ( ) on the Intervisibility Toolbar.


        image

        Intervisibility — Displaying Intervisibility Line Information

        image

      5. Displaying Intervisibility Line Information

        You can display the following information about an intervisibility line:

        • Location of each endpoint.

        • Heading of the line from each endpoint.

        • Altitude of each endpoint.

        • Length of the line (range).


          image

          Figure 46-6. Intervisibility line information (2D)

          The information label has a background. You can adjust the color and opacity of the background.

          To display information about an intervisibility line:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Intervisibility Settings page (Figure 46-5).

          3. Select or clear the Show Range and Bearing Labels check box.

          4. Select the check boxes for the type of information you want to display. For descrip- tions of the check box options, please see Table 46-1.

          5. To change the background color for the label:

            1. Click the Background Color button. A color picker opens.

            2. Select the color you want to use for the background.

            3. Click OK.

          6. To change the opacity of the background, adjust the Background Opacity slider.

          Intervisibility — Displaying an Intervisibility Line’s Terrain Profile

          image

      6. Displaying an Intervisibility Line’s Terrain Profile

        By default, a terrain profile window is displayed automatically when you create an intervisibility line. The terrain profile can be very helpful when you try to understand how terrain changes are affecting intervisibility. Figure 46-7 shows an obstructed inter- visibility line and its terrain profile, whose graph illustrates the line intersecting the terrain.


        image

        Figure 46-7. Terrain profile for an intervisibility line

        You can disable this setting on the Display Settings dialog box, Terrain Profile Settings page. For details, please see “Configuring Terrain Profiles,” on page 54-3.


      7. Deleting Intervisibility Objects

        Before you delete an intervisibility object, note the following:

    To delete an intervisibility object, select the object and choose Intervisibility

    Delete.


    image

    47. Sound Effects


    VR-Forces can play sound effects for entities, fire events, and detonation events.

    Introduction to Sound Effects 47-2

    Enabling Sound Effects 47-2

    Setting the Sound Volume 47-3

    Specifying the Range in which Sounds are Heard 47-3

    Associating Sound Files with Entities and Events 47-4

    Mapping a Sound File to an Entity 47-5

    Mapping Sound Files to Fire and Detonation Events 47-8

    Sound Effects — Introduction to Sound Effects

    image

      1. Introduction to Sound Effects

        VR-Forces can associate sound effects with entities, fire events, and detonation events. You can enable and disable use of sound effects and you can specify that sounds will be heard only when the observer is within a certain distance of the entity or event that generates them.


        image

        i Sound effects are not supported on Linux.

        image

      2. Enabling Sound Effects

        To enable sound effects:

        1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

        2. Select the Audio Settings page (Figure 47-1).


          image

          Figure 47-1. Audio Settings page

        3. Select the Enable Sound check box.


          image

          i

          i

          You can also enable and disable sound effects by clicking the Audio button image) on the Display Settings toolbar.


          image

          Sound Effects — Enabling Sound Effects

          image

              1. Setting the Sound Volume

                You can adjust the volume of sound effects.

                To set the sound volume:

                1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

                2. Select the Audio Settings page (Figure 47-1).

                3. Adjust the Volume slider.


                  image

                  i

                  i

                  You can also change the volume by clicking the arrow on the Audio button image) (on the Display Settings toolbar) and adjusting the Audio Volume slider.


                  image


              2. Specifying the Range in which Sounds are Heard

                You can specify that sound effects be played only if the observer is within a certain distance of the entities that can emit sounds. If sound range is enabled, as soon as the observer moves beyond the range from an entity, sound effects are shut off. If this option is disabled, sound effects are played for all entities in the scenario regardless of their distance from the observer. However, even if sound range is not enabled, as the distance between the observer and entities increases, sound levels drop off.

                To specify the range in which sounds can be heard:

                1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

                2. Select the Audio Settings page (Figure 47-1).

                3. Select the Enable Sound Range check box.

                4. Specify a value in the Sound Range text box.


      3. Associating Sound Files with Entities and Events

    VR-Forces includes a set of sound files (WAV format) for generic entity platforms and for fire and detonation events. The files are in ./data/Audio/Sounds. Sound files are asso- ciated with entity type enumerations. You can change the mappings and add new mappings.

    You add and edit mappings between entity types, fire events, or detonation events and sound files on pages in the Audio Settings dialog box. You can add or edit mappings using mapping dialog boxes or directly in the mappings windows. The mapping dialog boxes behave differently depending on the state of the mapping window when you open the dialog box, as follows:

    When you edit a mapping, the result depends on whether you edit the entity or event enumeration or the sound file. The differences are based on the requirements for uniqueness in a mapping. The uniqueness of an entity type or fire event mapping is based on the entity type enumeration. The uniqueness of a detonation event mapping is based on the entity type enumeration and the detonation result value. Table 47-1 lists the results of different editing actions.

    image

    Table 47-1: Editing sound mapping files


    Action Result

    Action Result

    Edit enumeration in dialog box. New mapping is added. The

    previous mapping is not changed.

    Edit enumeration in place. New mapping replaces previous

    mapping.

    Edit sound file in dialog box or in window.

    Edit channel in dialog box or in window.

    Mapping to current entity or event is updated.

    Mapping to current entity or event is updated.

    Edit detonation result in dialog box. New mapping is added. The

    previous mapping is not changed.

    Edit detonation result in window. New mapping replaces previous

    mapping.

    image


        1. Mapping a Sound File to an Entity

          An entity type enumeration can only have one sound file mapped to it. A sound file can be mapped to as many entity types as you want.


          Adding a New Entity Sound Mapping

          To add a new entity sound mapping:

          1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

          2. Select the Entity Sound Editor page (Figure 47-2).


            image

            Figure 47-2. Entity Sound Editor page

            image

          3. Click the Add button ( ). The Create New Entity Type Sound Mapping dialog box opens (Figure 47-3).


            image

            Figure 47-3. Create New Entity Type Sound Mapping dialog box


            image

            i

            i

            You cannot open the Create New Entity Type Sound Mapping dialog box with default options if one of the existing mappings is selected. If you have selected a mapping and want to return to the unselected state, click on white space in the mappings window or select one of the other tabs and then select the Entity Sound Editor tab again.


            image


          4. In the Entity Type box, type the enumeration for this mapping.


          5. In the Sound File text box, type the pathname of a sound file or click Browse and select a file in the file chooser dialog box.

          6. Click OK.


            image

            i

            i

            The OK button does not become enabled until you specify a valid entity type and sound file name.


            image


            Creating an Entity Sound Mapping from an Existing Mapping

            When you edit a mapping, you can either change the sound file associated with the current entity type or create a new mapping with a different entity type.

            To create a sound mapping from an existing mapping:

            1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

            2. Select the Entity Sound Editor page (Figure 47-2).

            3. Select the mapping that you want to use as the starting point.

              image

            4. Click the Add button ( ). The Create Entity Type Sound Mapping from Existing Mapping dialog box opens (Figure 47-4).


              image

              Figure 47-4. Create Entity Type Sound Mapping from Existing Mapping dialog box

            5. To change the sound file associated with the entity type, type a new pathname or click Browse and select a sound file.

            6. To create a new mapping, change the Entity Type enumeration.

            7. Click OK. If you just changed the sound file, the mapping is updated. If you changed the entity type, a new mapping is added to the list.


              Editing the Entity Type in the Mappings Window

              If you edit the entity type in the mappings window (that is, without using a dialog box), it replaces the previous mapping.

              To edit the entity type in the window:

              1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

              2. Select the Entity Sound Editor page (Figure 47-2).

              3. Double-click the entity type you want to edit. It becomes editable (Figure 47-5).


                image

                Figure 47-5. Editable entity type

              4. Change the entity type enumeration.

              5. Press Enter.


            Editing the Sound Mapping in the Mappings Window

            When you edit the sound mapping in the mappings window, the change does not affect any other mapping.

            To edit the sound mapping in the window:

            1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

            2. Select the Entity Sound Editor page (Figure 47-2).

            3. Double-click the sound mapping that you want to change. The Sound File dialog box opens.

            4. Select the new sound file.

            5. Click Open.


        2. Mapping Sound Files to Fire and Detonation Events

          When you map a sound file to a weapon fire or a detonation event, you can specify a channel for the sound. When you map a detonation sound, you can specify the detona- tion result for the mapping.

          Specifying a channel for a sound event lets you control the number of sounds that can play concurrently. Sounds that are mapped to channel 0 can all play at the same time. Sounds mapped to any other channel can play only if no other event is using the channel. For example, suppose you map two weapon fire events to channel 1. One of the weapon type fires and the sound is generated. Then the second type of weapon event occurs. Since the first event is using channel 1, the second sound is not generated.

          The SISO Enumerations document specifies a list of detonation results, such as Entity Impact, Ground Impact, and Air Hit. The detonation result is part of the detonation message sent over the network. You can specify that a detonation sound be played only for a certain type of detonation result. If you set the result to “any” it plays for any type of detonation. If, for a particular detonation type, you map one sound to “any” and another sound to a specific detonation result, the specific detonation result takes prece- dence.


          image

          i

          i

          You can change fire and detonation mapping settings directly, rather than using the sound mapping dialog box, just like you can change entity type sound mappings. For details, see the sub-procedures under “Mapping a Sound File to an Entity,” on page 47-5.


          image


          To map a sound file to a weapon fire or detonation:

          1. Choose Settings Audio Settings. The Audio Settings dialog box opens.

          2. Select the Fire Sound Editor page or Detonation Sound Editor page (Figure 47-6), as appropriate.


            image

            Figure 47-6. Detonation Sound Editor page

            image

          3. Click the Add button ( ). The Create New Detonation (or Weapon Fire) Sound Mapping dialog box opens (Figure 47-7).


            image

            Figure 47-7. Create New Detonation Sound Mapping dialog box


            image

            i

            i

            When you click the Add button, if you have selected a mapping in the list, the Create New Sound Mapping from Existing dialog box displays the values for the selected mapping. If you change the entity type or detonation result, a new mapping is added with the new values.


            image


          4. In the Entity Type box, type the enumeration for this mapping.

          5. Optionally, for detonation sounds, select an option on the Detonation list.

          6. In the Sound File text box, type a pathname for the sound file you want to use or click Browse and select a file in the file choose dialog box.


          7. Optionally, specify a channel in the Channel box.

          8. Click OK.


    image

  3. The Observer and Viewing Scenarios


    The observer, or eyepoint, is the location in the 3D or 2D environment from which you observe the scene. You can move the observer (navigate) through the scene. You can attach the observer to a simulation object or prop. When the observer is attached to a simulation object, it moves automatically with that object. You can also control the observer from a remote application using view control messages.

    You can have multiple observers in a VR-Forces session. They might be associated with different windows. For example you could have an observer for the main window and one for an inset window.

    The observer is such a pervasive component of the VR-Forces front-end that it is not covered in just one chapter of this manual. For more information, please see:

  4. Terrain


    Each simulation takes place within the extents of a terrain database. A terrain database provides three-dimensional information about a geographic area and provides the envi- ronment within which simulation objects function. With the information in a terrain database, VR-Forces calculates height, intervisibility, and other three-dimensional information.

    VR-Forces allows you to load terrain data in the following basic ways:

  5. Creating and Editing Simulation Models


    This section explains how to use the Simulation Object Editor and OPD Editor to create and edit simulation model sets and the simulation models used by simulation objects. It also covers configuration files that you must edit by hand.



    Section XI - Creating and Editing Simulation Models VR-Forces Users Guide


    XI-1



    Section XI - Creating and Editing Simulation Models

    XI-2 VT MAK


    image 64. The Simulation Object Editor and SMSs


    The Simulation Object Editor is a stand-alone tool that lets you configure simulation objects and tactical graphics, and create new simulation model sets.

    Introduction to the Simulation Object Editor 64-3

    Starting the Simulation Object Editor 64-4

    Simulation Model Sets 64-5

    Including Simulation Model Sets in other Simulation Model Sets 64-6

    SMS Priority for Included and Multiple SMSs 64-8

    Lua Scripts in Included SMSs 64-9

    Application Level Files in Included SMSs 64-9

    Search Paths for Referenced Files in an SMS 64-10

    Promoting a Model to the Loaded SMS 64-11

    Visual Model Definitions 64-12

    User-Created Visual Definition Files 64-12

    Migrating an SMS to a New Release 64-13

    Upgrading Old Simulation Model Sets 64-14

    Opening a Simulation Model Set 64-16

    Creating a New Simulation Model Set 64-17

    Creating a Completely New Simulation Model Set 64-18

    Specifying the Default Simulation Model Set for Scenarios 64-18

    Importing .entity Files 64-18

    Applying Platform Updates 64-19

    Editing the Category List 64-19

    Adding a New Category 64-20

    Removing a Category 64-20

    Renaming a Category 64-21

    image

    The Simulation Object Editor and SMSs

    Undoing Category Changes 64-21

    Managing the Forces List 64-22

    Adding a Force 64-22

    Editing a Force 64-23

    Removing a Force 64-24

    The Simulation Object Editor and SMSs — Introduction to the Simulation Object Editor

    image

      1. Introduction to the Simulation Object Editor

        The Simulation Object Editor lets you create and edit simulation model sets and the objects in them.

        Many VR-Forces users want to edit some or all of the following simulation object char- acteristics:

      2. Starting the Simulation Object Editor

        To start the Simulation Object Editor in Windows, choose MÄK Technologies VR-Forces 4.5 Tools Simulation Object Editor. The Simulation Object Editor opens (Figure 64-1).


        image

        Figure 64-1. Simulation Object Editor

        To start the Simulation Object Editor from the command-line in Windows or Linux:

        1. Change directory to ./bin64.

        2. Run:

        simulationObjectEditor options

        Table 64-1 describes the command-line arguments for the Simulation Object Editor.

        image

        Table 64-1: Simulation Object Editor command-line arguments


        Argument Description

        Argument Description

        (-- | --ignore_rest) Ignores the rest of the labeled arguments following

        this flag.

        --appDataDir directory Specifies the location of application data.

        --dataDir directory Specifies the location of the data directory (terrains

        and so on).

        --doNotCheckPluginVersions Do not check versions in the plug-ins to make sure

        they can load against this version of the application.

        --doNotLoadVrfPlugins Do not load the plug-ins contained in XML files in the

        ./plug-ins directory.

        image


        image

        Table 64-1: Simulation Object Editor command-line arguments


        Argument Description

        Argument Description

        (-G | --locale) language The name of the language to load into the GUI.

        (-h | --help) Displays usage information and exits.

        --launcherLocation

        location

        --layoutSettingsFile

        filename

        Specifies the location of the VR-Forces launcher.


        Specifies the GUI layout settings file to use. filename specifies the base filename. It is prefixed with default_ and the extension .uisx is added. Default: SOEUILayoutSettings.

        --loadPlugin filename Load the specified Simulation Object Editor plugin.

        Can be a specific plug-in or plug-in XML file.

        --opdEditorLocation string Location of the OPD Editor application.

        --settingsDirectory string Sets the directory to load all ui and settings files

        from.

        --showConsole Show the console.

        --smsFile string Loads the specified SMS file.

        (-v | --version) Displays version information and exits.

        --visualTerrain string Terrain used when displaying simulation objects.

        image


      3. Simulation Model Sets

        A simulation model set (SMS) defines all of the simulation objects, tactical graphics, and other object models that you can create in a VR-Forces simulation. The simulation model set file tells VR-Forces where to find all of the configuration files it needs to create, simulate, and display simulation objects and other objects. Every scenario must reference one or more simulation model sets.

        If you use the Simulation Object Editor to edit simulation object models, the only configuration file that you need to be aware of is the simulation model set file that you are using. All of the other files are handled by the Simulation Object Editor.

        VR-Forces provides the following SMSs:

        • base.sms. Defines platforms and graphics used by other SMSs.

        • EntityLevel.sms. Defines entities, units, and other objects used for entity-level scenarios. Includes base.sms.

        • AggregateLevel.sms. Defines units and other objects used for aggregate-level scenarios. Includes base.sms.

    For details about entity-level modeling and aggregate-level modeling, please see “Entity-Level Modeling and Aggregate-Level Modeling,” on page 15-10.


    image

    !

    !

    When you use the Simulation Object Editor, you are editing a simulation model set. We recommend that you keep the default SMSs as reference model sets and not edit them. If you want to edit entity models, create a new SMS based on one of the provided SMSs and use it as the default SMS for your scenarios. For details about creating a new SMS and changing the default SMS, please see “Creating a New Simulation Model Set,” on

    page 64-17.


    image


        1. Including Simulation Model Sets in other Simulation Model Sets

          VR-Forces simulation model sets can include other SMSs. This allows you to create core SMSs that can be included in multiple other SMSs that may have incompatible characteristics or which override some characteristics of the core SMS, but which still need core objects.

          VR-Forces provides three SMSs, base.sms, EntityLevel.sms, and AggregateLevel.sms. Enti- tyLevel.sms and AggregateLevel.sms both include base.sms, which has platform files and graphics that they both need.

          It is important to understand the difference between using an SMS that includes other SMSs and creating a scenario that uses multiple SMSs. Since VR-Forces users usually create new SMSs to configure new types of simulation objects, or add new systems to existing objects, we will consider the differences in that context.

          If you want to create a custom stand-alone SMS for a new or enhanced object, that SMS must include all of the files required to support that object, such as an OPE file, entity file, system files, damage files, and so on. When trying to build such an SMS, it can be easy to overlook required files. This process also requires you to duplicate files that are contained in the supplied SMSs even if you do not need to change them, because the SMS must contain all the files it needs. Then, if you do not load the SMSs in the correct order, your customization can be overridden by one of the other SMSs you are using in the scenario. In summary, it is a cumbersome process that can create needless duplication of files and be difficult to debug if problems arise.

          Using included SMSs minimizes the problems inherent in using multiple stand-alone SMSs. When an SMS includes another SMS, it has a higher priority than the included SMS. When an SMS is loaded, included SMSs are loaded first, and each subsequent SMS has a higher priority than the previously loaded SMS. Any parameters or files in the higher priority SMSs that are also in the lower priority SMSs override those in the lower priority SMSs. The higher priority SMSs do not need to contain any files that they do not change from the included SMSs. Therefore the total footprint of the SMS is smaller.


          To include an SMS in another SMS:

          1. Choose MÄK Technologies VR-Forces 4.5 Tools Simulation Object Editor. The Simulation Object Editor opens (Figure 64-1).

          2. Choose File Open Simulation Model Set. The Open Model Set dialog box opens.

          3. Select the parent SMS.

          4. Click Open. The SMS is loaded.

          5. Choose Edit Included Simulation Model Sets. The Edit Included Simulation Model Sets dialog box opens.


            image

            Figure 64-2. Edit Included Simulation Model Sets dialog box

            image

          6. Click the Add button ( ). A line is added to the window with the text <empty file>.

          7. Click the Browse button at the end of the line. The Choose File dialog box opens.

          8. Select the SMS that you want to include.

          9. Click Open. The SMS is added to the list in the window.

          10. Click OK. The SMS is saved and reloaded.


        2. SMS Priority for Included and Multiple SMSs

          When you load multiple SMSs either through inclusion or by specifying multiple SMSs for a scenario, conflicts are resolved through the priorities of the SMSs.

          For included SMSs, priority is based on the inclusion relationships. The highest level SMS is loaded last and has the highest priority. Simulation objects in higher priority SMSs override those in lower priority SMSs. For example, suppose you create a new SMS called mySMS that includes EntityLevel.sms. EntityLevel.sms already includes base.sms. When VR-Forces loads mySMS it loads base.sms first. Then it loads Enti- tyLevel.sms, and finally mySMS. Objects in mySMS override objects in EntityLevel.sms that have the same object type, which in turn overrides base.sms.

          When you load multiple SMSs, priority is based on the order in which they are loaded. Assuming a simple case of two SMSs that do not include other SMSs, if the second SMS loaded specifies objects that are also in the first SMS loaded, the specification in the second SMS takes precedence.

          If you load multiple SMSs that include other SMSs, priority is based on the order loaded, but duplicate SMSs are not loaded twice. Assume the SMS organization shown in Figure 64-3.


          mySMS.sms

          image EntityLevel.sms

          image base.sms

          yourSMS.sms

          image EntityLevel.sms

          image base.sms


          Figure 64-3. Multiple SMSs

          If mySMS.sms is the first SMS loaded, VR-Forces loads base.sms, then EntityLevel.sms, then mySMS.sms. Priority is determined as described previously for an SMS with included SMSs. Then VR-Forces loads yourSMS.sms. It starts with base.sms. Since base.sms is already loaded, VR-Forces ignores it. Then it moves to EntityLevel.sms. Since EntityLevel.sms is already loaded, it ignores it. Then it loads yourSMS.sms. If yourSMS.sms has objects that conflict with mySMS.sms, then yourSMS.sms overrides them.

          The overall priority for the SMSs in this example, from lowest to highest, is base.sms, EntityLevel.sms, mySMS.sms, yourSMS.sms.

          The priority of multiple SMSs is determined by the order in which they are listed in the Simulation-Model-Set-Files parameter in the scenario file. In the following example, Enti- tyLevel.sms has the highest priority. When you create a scenario and list multiple SMSs, the priority in the SMS list is top to bottom.

          (Simulation-Model-Set-Files "..\data\simulationModelSets\EntityLevel.sms" "..\data\simulationModelSets\developer_toolkit_examples\addTask.sms")


        3. Lua Scripts in Included SMSs

          System scripts are stored in simulation model sets. When you load an SMS that includes another SMS, the scripts in the highest priority SMS supersede those in the lower priority SMSs.

          The highest priority scripts get used by all simulation objects, regardless of which SMS they are in. For example, suppose EntityLevel.sms has a script called Patrol Area and mySMS.sms (the higher priority SMS) also has a script called Patrol Area. If the entity M1A2, which is defined in EntityLevel.sms executes the Patrol Area task, it will use the version in mySMS.sms.

          Lua scripts in included SMSs have the following additional relationships:

          • Any scenario scripted task promoted to a system scripted task is promoted into the highest-priority SMS.

          • If you edit a scripted task that is in an included SMS, it is saved into the highest- priority SMS. The version of the script in the included SMS does not change. Therefore if you want a change to a script to affect all uses of that script, edit it in its own SMS.


        4. Application Level Files in Included SMSs

          Application-level SMS files, such as commModelParams.mtl or gui/initialCreateMenuCo- nfiguration.xml, are included the same way entity-specific files are and you do not need to have copies of them in a parent SMS as long as one of the child SMSs has them.

          However every SMS must have vrfSim.opd.


        5. Search Paths for Referenced Files in an SMS

          The simulation objects in a scenario reference many files to determine their behavior, such as system definition files, damage tables, ammunition selection tables and so on. If all the simulation objects in a scenario are configured in one SMS, then all of the refer- enced files are within the file hierarchy of that SMS. However, if you use an SMS that includes other SMSs, then simulation objects may have to search within multiple SMSs to reference the correct files.

          An SMS can load files from any SMS it includes, and any currently loaded SMS it is included in.

          File referencing, as with other aspects of included SMSs, is based on the priority of the SMS in which an object is configured. Given the SMSs in Figure 64-3, the search paths for each SMS, from lowest to highest priority would be:

          • base.sms. Can search in base.sms, EntityLevel.sms, mySMS.sms, and yourSMS.sms.

          • EntityLevel.sms. Can search in base.sms, EntityLevel.sms, mySMS.sms, and

            yourSMS.sms.

          • mySMS.sms. Can search in base.sms, EntityLevel.sms, and mySMS.sms.

          • yourSMS.sms. Can search in base.sms, EntityLevel.sms, and yourSMS.sms.


        6. Promoting a Model to the Loaded SMS

          When you load an SMS that has included other SMSs, the objects from the included SMSs are listed, but you cannot edit them. You can only edit them by editing the SMS to which they belong. Figure 64-4 shows the Space category for addEntity.sms. (It is in the developer toolkit examples for the addEntity example.) The Space Shuttle entity that is part of the parent SMS is editable, but the two entities included from Enti- tyLevel.sms are not. Note in the figure that most of the parameters for the Space Shuttle in EntityLevel.sms are read-only.


          image

          Figure 64-4. addEntity.sms

          Since one of the purposes of being able to include SMSs in the loaded SMS is to customize simulation objects in the included SMSs, you can promote objects from the included SMS to the loaded SMS. The object then becomes editable and is saved in the loaded SMS. When the SMS is loaded, the object in the loaded SMS overrides the object in the included SMS.

          To promote an object to the parent SMS:

          1. Load the parent SMS.

          2. Select the object you want to promote.

          3. Choose Model Promote to Main Simulation Model Set. The object is added to the parent SMS and is now fully editable. When you save the SMS, a new .entity file is added to it.

    The Simulation Object Editor and SMSs — Visual Model Definitions

    image

      1. Visual Model Definitions

        VR-Forces stores visual model definitions in different places depending on which SMS is loaded, as follows:

        • When the Simulation Object Editor loads base.sms, EntityLevel.sms, or Aggre- gateLevel.sms, it reads the appropriate definition files for the SMS from the directo- ries under ./appData/definitions. When you save changes to one of these SMSs, the changes are written back to the original definition files.

        • If you create a new SMS, model and element definition files get saved with the SMS in the ./data/simulationModelSets/<sms>/gui/visuals directory for the new SMS. When you load the SMS, it reads model and element definitions from the SMS- specific files.

    For information about model and element definition files, please see Chapter 81, Model and Element Definitions.


        1. User-Created Visual Definition Files

          Although we recommend that you use the Simulation Object Editor for all changes to visual models, it is possible to add new model definitions and element definitions using the Visual Model Editors dialog box, instead of the Simulation Object Editor. Addi- tionally, some attributes of element definitions cannot be set in the Simulation Object Editor, so if you want to change them, you have to use the Visual Model Editors.

          The new and changed definitions can be exported to files other than the default set of definition files. In fact, in many cases, we recommend that you export them to their own files. However, creating new model or element definitions in the Visual Model Editors and saving them to new files has implications for how they are loaded and saved by the Simulation Object Editor.

          When the Simulation Object Editor loads one of the three default SMSs, it loads all files in the appropriate directories, including any additional files that you have created. However, when VR-Forces saves changes to the SMS, it writes the changes only to the default definition files for the SMS. It does not write back to the user-created definition files. Since the user-created files are still in the directory, the next time you load the SMS, there may be conflicts between the files and the results may be unexpected.

          Given this behavior, the recommended work flow for reconciling new definitions created in the Visual Model Editors dialog box is as follows:

          1. In the Visual Model Editors dialog box, save new model or element definitions to new files in the default definition directories.

          2. Open the affected SMS in the Simulation Object Editor.

          3. Confirm that your new model or element definitions have been loaded by the SMS.

          4. Save the SMS. This saves the new definitions into the default set of SMS definition files.


          5. Delete the individual definition files that you created in step 1 so that there are no conflicts with the SMS.

    If you create a new SMS, when the Simulation Object Editor loads the SMS, it only loads the definition files that it previously created. If you create additional leaf or model definition files with the Visual Model Editors dialog box, they do not get loaded. You must import them into your SMS. Therefore the recommended work flow is as follows:

    1. Open a scenario that uses your SMS.

    2. In the Visual Model Editors dialog box, load the .hier file for your SMS. It is either

      ./appData/definitions/Aggregate/ElementDefinitions/coreAggregateElementDefini- tions.hier or ./appData/definitions/Entity/ElementDefinitions/coreEntityElementDefi- nitions.hier.

    3. Import the model definition or element definition file to which you want to add new definitions. Be sure to import it from the files in the /gui/visuals directory for your SMS. Be sure that you only edit one element definition file at a time.

    4. Add new definitions as desired.

    5. Export the new definitions to the definition file that you imported.

    6. Open the SMS in the Simulation Object Editor and confirm that the new defini- tions are available.


      1. Migrating an SMS to a New Release

        The Simulation Object Editor includes an option for upgrading old SMSs. You can also update them by hand.

        When you edit an SMS in the Simulation Object Editor, it:

        • Creates or edits .entity files for the simulation objects that you edit.

        • Modifies visual definition files and entity type mappings.

    The Simulation Object Editor does not create or change any other files. It is possible that you may add or edit some of the files that entity systems reference, such as damage files. You might also create or modify scripts that are stored in an SMS.

    If you upgrade to a new version of VR-Forces, you can quickly add any of the new simulation objects you created by copying their .entity files into an SMS in the new release. This will make the simulation objects available to the simulation engine, but will not include their visual definitions. For each entity that you add this way, you will have to edit the 2D and 3D models in the Simulation Object Editor.

    If you made any changes to other files, you may have to copy those changed files to the new SMS.

    If you have written scripts, use the script export process to export them from the previous release of VR-Forces and then import them into the new release.

    The Simulation Object Editor and SMSs — Migrating an SMS to a New Release

    image


    Over time, the SMS format has changed. The Simulation Object Editor has a process for upgrading older SMSs. For details, please see “Upgrading Old Simulation Model Sets,” on page 64-14.


        1. Upgrading Old Simulation Model Sets

          The SMS organization changed considerably from VR-Forces 4.1.x to 4.2. At that time, SMSs started using .entity files to configure individual simulation objects. In VR- Forces 4.3, the ability to include SMSs in other SMSs was added. The SMS upgrade tool helps you migrate SMSs through these different transitions.

          If you need to migrate a pre-VR-Forces 4.2 SMS, the upgrade tool converts your old SMS into the XML file format used for VR-Forces 4.2 and later. If you upgrade an SMS from VR-Forces 4.2 to 4.3 or later, it takes into account the transition from the default.sms to EntityLevel.sms, which includes base.sms.

          When you upgrade a 4.2 or later SMS, you create a completely new SMS. The upgrade tool:

          • Copies all files except .entity and simulation object group (.sog) files from a current SMS (that is, an SMS from the latest version of VR-Forces) into the new SMS. (Optionally, you can copy all .entity and .sog files to the new SMS. The tool does not copy all .entity files by default because users often create SMSs with new simu- lation objects or a small subset of the simulation objects in the SMSs provided with VR-Forces. The default behavior is to create a new SMS that only has the simula- tion objects in the SMS being upgraded.)

          • Copies all of the files from the old SMS, including .entity files, but not .opd or .mst files, into the new SMS, if necessary. (Files that are part of an included SMS are not copied.) If .entity files in the old SMS match the names of files in the current SMS, the old files overwrite the current files.

          • If the following file types with the same name have different content, the tool warns you about these differences. You must reconcile them manually.

            • xml

            • lua

            • sysdef

            • mtl

            • tsk

            • ui.


    To upgrade an old SMS:

    1. Open the Simulation Object Editor.

    2. Choose File Upgrade Old Simulation Model Set. The Select SMS to Upgrade dialog box opens (Figure 64-5).


      image

      Figure 64-5. Select SMS to Upgrade dialog box

    3. Select the SMS you want to upgrade.

    4. Specify a name for the new SMS.

    5. Specify the SMS you want to base the new SMS on – EntityLevel.sms or Aggre- gateLevel.sms.

    6. Optionally, select Copy Entity Files from Current SMS.

    7. Click Finish. The upgrade tool runs.

    The Simulation Object Editor and SMSs — Opening a Simulation Model Set

    image

      1. Opening a Simulation Model Set

        To edit simulation object models in the Simulation Object Editor, you must open a simulation model set.

        To open a simulation model set:

        1. Choose File Open Simulation Model Set. The Open Model Set dialog box opens.

        2. Select the SMS you want to open.

        3. Click Open. The SMS is loaded and a list of simulation objects is displayed in the Simulation Object Editor.



          image

          Entity list



          Figure 64-6. Simulation Object Editor with simulation model set loaded

          The Simulation Object Editor and SMSs — Creating a New Simulation Model Set

          image

      2. Creating a New Simulation Model Set

        You can create new SMSs by copying and editing an existing SMS or you can create a completely new SMS and create the simulation objects that you want to include in it. When you create a new SMS, you can specify that it include other SMSs.

        To create a new simulation model set from an existing SMS:

        1. Choose File New Simulation Model Set. The New Simulation Model Set dialog box opens (Figure 64-7).


          image

          Figure 64-7. New Simulation Model Set dialog box

        2. Select Create From Existing Simulation Model Set.

        3. Click Next. The Select Model Set to Copy dialog box opens.

        4. Select a model set and click Next. The Include Simulation Model Sets dialog box opens. It lists the SMSs included in the SMS that you are copying.

        5. Optionally, edit the list of SMSs to be included. (For details about how to add and remove included SMSs, please see the procedure in “Including Simulation Model Sets in other Simulation Model Sets,” on page 64-6, starting with step 6.)

        6. Click Next. The New Model Set Name dialog box opens.

        7. In the File name box, type a name for the new model set.

        8. Click Finish. The Simulation Object Editor loads information from the source model set.

        9. Make any changes you want to the model set.

        10. Choose File Save Simulation Model Set.

    The Simulation Object Editor and SMSs — Importing .entity Files

    image

        1. Creating a Completely New Simulation Model Set

          To create a completely new simulation model set:

          1. Choose File New Simulation Model Set. The New Simulation Model Set dialog box opens (Figure 64-7).

          2. Select Create New Simulation Model Set.

          3. Click Next. The New Model Set Name dialog box opens.

          4. In the File name box, type a name for the new model set.

          5. Click Finish. The Simulation Object Editor loads systems information from the default model set.

          6. Create the simulation objects that you want to have in the model set, as described in “Creating a New Simulation Object,” on page 65-32.

          7. Choose File Save Simulation Model Set.


        2. Specifying the Default Simulation Model Set for Scenarios

    When you create a new scenario, the New Scenario dialog box lists EntityLevel.sms as the SMS to use. You can change the default SMS. For details, please see “Specifying the Default SMS Configuration,” on page 7-11.


      1. Importing .entity Files

        If you have .entity files that you created with a previous version of VR-Forces or by multiple persons on different computers, you may want to import them into an SMS. The easiest way to do this is to copy the files into the vrfSim directory in the SMS (./data/simulationModelSet[<model_set>/vrfSim). However, you can also import the files from the Simulation Object Editor.

        To import .entity files into an SMS:

        1. Choose File Add Entity File. The Add Entity File dialog box opens.

        2. Select the file that you want to import.

        3. Click Open. The file gets copied to the SMS.


      2. Applying Platform Updates

        All simulation object models reference one of the basic platforms, such as ground, fixed-wing, and point object. Most simulation objects reference one or more system definition files. If you update the variable bindings in a platform file or system defini- tion file, you must apply these changes to the simulation objects of that platform type. Although you could do this by hand, as described in “Adding Variable Bindings to Plat- form and System Files,” on page 69-21, that would be a tedious and error-prone activity. The Simulation Object Editor can apply all updates to all files automatically.

        To apply platform updates:

        1. Choose File Apply Platform Updates. An information prompt opens.

        2. Click OK.


      3. Editing the Category List

    If you want to organize simulation objects into categories that are not included in the default category list, you can add new categories. You can also remove and rename cate- gories.


    image

    i

    i

    The procedures in this section also apply to editing the Used By Countries list. Select Used by Countries on the Edit menu instead of Categories.


    image

    The Simulation Object Editor and SMSs — Editing the Category List

    image

        1. Adding a New Category

          To add a new category:

          1. Choose Edit Categories. The Categories Editor opens (Figure 64-8).


            image

            Figure 64-8. Categories Editor

          2. Click Add. The New Category dialog box opens.

          3. Type the name of the new category.

          4. Click OK. The new category is added to the list in the Categories Editor.

          5. Click OK.


            image

            i

            i

            If you add a category and do not assign a simulation object to it, it does not get saved when you save the simulation model set.


            image


        2. Removing a Category

          If you remove a category, it gets removed from any entity that is assigned to it. You must save the SMS to make the change permanent.

          To remove a category:

          1. Choose Edit Categories. The Categories Editor opens.

          2. Select the category that you want to remove.

          3. Click Remove.

          4. Click OK.


        3. Renaming a Category

          When you rename a category, all simulation objects that are assigned to the old name are reassigned to the new name. The old name remains in the Categories list until you save the simulation model set, but it is not listed in the Categories Editor. If you assign a simulation object to the old category name before saving the SMS, the old name is retained and added to the list in the Categories Editor.

          To rename a category:

          1. Choose Edit Categories. The Categories Editor opens.

          2. Select the category that you want to rename.

          3. Click Rename. The Rename dialog box opens.

          4. Type the new name.

          5. Click OK. The categories list is updated.

          6. Click OK.


        4. Undoing Category Changes

          You can undo changes made to the category list and entity category assignments.


          image

          !

          !

          When you undo category changes, all changes to the categories list and all changes to entity category assignments made since the last save of the simulation model set are reversed. Be sure that this is what you want before completing this procedure.


          image


          To undo category changes:

          1. Choose Edit Revert Categories. A confirmation prompt is displayed.

          2. Click Yes.


      1. Managing the Forces List

        When you create an object in the front-end, you must choose a force. You manage the list of forces available and their coloring in the Simulation Object Editor.


        1. Adding a Force

          Adding new forces may be useful if you are simulating participants from multiple coun- tries or if you want to easily model and change force relationships for non-govern- mental forces such as militias or insurgent groups.

          To add a force:

          1. Choose Edit Forces. The Forces Editor opens (Figure 64-9).


            image

            Figure 64-9. Forces Editor

          2. Click Add. The Force Hostility Editor opens (Figure 64-10). The new force is assigned a force ID. You cannot edit the force ID.



            image

            Figure 64-10. Force Hostility Editor

          3. In the Force Name box, type a name for the force.

          4. Click the Color button. A color picker opens.

            The Simulation Object Editor and SMSs — Managing the Forces List

            image


          5. Select a color for the force.

          6. Optionally, in the Hostile Against window, select the forces that the new force will be hostile towards. (You can change hostility at run time in the Hostility Matrix. For details, please see “Managing Force Hostility Relationships,” on page 9-10.

          7. If you want the force to be listed in dialog boxes that list forces, select the Include in Dialogs check box.

          8. Click OK.

          9. Click Close.


        2. Editing a Force

          You can edit a force’s name, color, hostility, and use. Each force has a force number. When you edit a force, you are changing the attributes of that numbered force.

          To edit a force:

          1. Choose Edit Forces. The Forces Editor opens (Figure 64-9).

          2. Select the force that you want to edit.

          3. Click Edit. The Force Hostility Editor opens (Figure 64-10).

          4. To edit the name, change the text in the Force Name box.

          5. To edit the color associated with the force, click the Color button and choose a color from the color picker.

          6. To edit hostility relationships, in the Hostile Against window, select the forces that the force should be hostile towards.

          7. To edit whether or not the force is listed in dialog boxes that list forces, select or clear the Include in Dialogs check box.

          8. Click OK.

          9. Click Close.


        3. Removing a Force

          If you create a scenario that has simulation objects with a particular force and you then remove the force, the next time you open the scenario, VR-Forces still maintains that force assignment for the simulation objects. The force will be listed in the Hostility Matrix. However, entity icons will not be colored and you will not be able to create any simulation objects with the removed force.

          To remove a force:

          1. Choose Edit Forces. The Forces Editor opens (Figure 64-9).

          2. Select the force that you want to remove.

          3. Click Remove. The force is removed from the list.

          4. Click Close.


    image

    65. Editing Simulation Object Models


    This chapter explains how to use the Simulation Object Editor to edit individual objects in EntityLevel.sms. Many of the concepts and procedures also apply to units. For details about editing units, please see Chapter 66, Editing Units for Entity-Level Scenarios and Chapter 67, Editing Aggregate-Level Objects.

    Editing Generic Object Parameters 65-3

    Selecting an Object to Edit 65-3

    Editing an Object’s Categories 65-3

    Changing an Object’s Object Type Enumeration 65-4

    Changing an Object’s Name 65-7

    Specifying Whether an Object Can Be Created 65-7

    Specifying the Object Creation Palette 65-7

    Specifying the Default Overlay 65-8

    Specifying the Platform 65-8

    Undoing (Reverting) Changes to an Object 65-8

    Editing Parameters that are Specific to Simulation Objects 65-9

    Editing a Simulation Object’s Used By Countries List 65-9

    Editing a Simulation Object’s Bounding Volume (Size) 65-10

    Displaying a Simulation Object’s Bounding Volume 65-11

    Specifying Support Points 65-12

    Excluding Entities from Batch Bounding Volume and Support Point Updates 65-12

    Editing Behavioral Parameters 65-12

    Adding Object Geometry to an Entity 65-14

    Ground Clamping Cultural Features 65-15

    Editing a Lifeform’s Visual Model and Animation 65-16

    Editing a Simulation Object’s Visual Model 65-19

    image

    Editing Simulation Object Models

    Changing the 3D Model or Colorized Model 65-20

    Changing the 2D Icon Using a Font 65-21

    Changing the 2D Icon Using an Image 65-21

    Editing a Spot Report Icon 65-23

    Adding a New Visual Model or Image 65-24

    Displaying Details about the Visual Model 65-25

    Importing Visual Models 65-26

    Pruning Visual Models 65-26

    Exporting Visual Models 65-27

    Reloading Visual Models in the VR-Forces GUI 65-27

    Editing a Simulation Object’s Systems 65-28

    Adding a System 65-30

    Selecting a Damage Model 65-30

    Selecting a Movement Model 65-30

    Editing a System’s Properties 65-31

    Editing a System in the OPD Editor 65-31

    Removing a System 65-32

    Creating a New Simulation Object 65-32

    Creating a New Model from an Existing Model 65-33

    Deleting an Object Model 65-34

    Configuring Embarkation 65-34

    Adding Ingress and Egress Points 65-36

    Configuring Slots 65-38

    Configuring Wakes 65-41

    Creating Randomized Simulation Objects 65-43

    Creating a Simulation Object Group 65-45

    Setting the Simulation Connection when Creating an SOG 65-46

    Navigating Among Edited Simulation Objects 65-46

    Configuring Scripted Entity Movement 65-47

    Configuring Ballistic Missile Movement 65-48

    Configuring Animated Movement 65-50

    Editing Movement File Configurations 65-51

    Editing Tactical Graphics 65-53

    Editing a Tactical Graphic’s Menu Icon 65-53

    Setting the Default Values for Tactical Graphics Properties 65-54

    Specifying the Properties that can be Edited in the Front-End 65-55

    Editing the Visual Model for a Tactical Graphic 65-56

      1. Editing Generic Object Parameters

        This section explains how to edit the parameters that are common to most objects. The procedures in this section apply to simulation objects, tactical graphics, cultural features, and other objects such as weather and contamination areas.


        image

        i

        i

        If one of the object parameters described in this section does not apply to a particular object type, it is either blank or uneditable in the Simulation Object Editor.


        image


        1. Selecting an Object to Edit

          Most of the Simulation Object Editor procedures assume that you have selected an object in the object list to edit.

          To select an object to edit:

          1. Optionally, in the object list, select the category for the type of object you want to edit.

          2. Select the object in the list.


        2. Editing an Object’s Categories

          Objects are organized by categories on the Create menu and the object creation palettes. You can change the categories that an object is part of. For details about adding new categories to the list, please see “Adding a New Category,” on page 64-20.

          To assign an object to a category, in the Categories list, select the check boxes for the categories you want it to be part of and clear the check boxes for the categories that you do not want (Figure 65-1).


          image

          Figure 65-1. Categories list


        3. Changing an Object’s Object Type Enumeration

          The Simulation Object Editor lets you change an object’s object type (DIS/RPR enumeration) and matching type. (For details about published and matching object types, please see “Published Object Types and Matching Object Types,” on page 69-6.) You might want to or have to do this for any of the following reasons:


          image

          i

          i

          The Entity Enumeration value displayed in the Simulation Object Editor is the 7-digit DIS or RPR FOM enumeration that VR-Forces uses to build the published object type. The matching object type is not displayed in the Simulation Object Editor, but you can specify it in the Change Enumeration dialog box as described in this procedure.


          image


          To change an object’s enumeration:

          1. Select the object in the object list.

          2. Click Edit next to the Entity Enumeration text box (Figure 65-2). The Change Enumeration dialog box opens (Figure 65-3).


            image

            Figure 65-2. Object enumeration


            image

            Figure 65-3. Change Enumeration dialog box

          3. Edit the enumeration by selecting options from the lists for enumeration elements or type a new enumeration in the Object Type text box.


          4. Optionally, specify the Matching Type as follows:

            1. Click Advanced. The dialog box expands (Figure 65-4).


              image

              Figure 65-4. Change Enumeration dialog box, Advanced

            2. For each field in the matching type enumeration that you want to be a wild card (-1), select the appropriate check box.

          5. Optionally, clear the Apply Change to All Matching Subordinate Types check box. Usually you will want an enumeration change to affect all cases where this simula- tion object will be created. However, if there is some reason that you want an enumeration change to not affect simulation objects created as part of a unit, you can do that by clearing this check box. A more straightforward approach would be to create a new simulation object from the existing simulation object rather than changing the enumeration.

          6. Click OK. The enumeration changes.


        4. Changing an Object’s Name

          The object name is the name listed on the object creation palettes and Create menu. The text placed on the screen next to a 2D icon is the marking text. The marking text is based on the Short Name, which is configured in the Attributes section of the Simula- tion Object Editor (Figure 65-8).

          To change an object’s name:

          1. Select the object in the object list.

          2. Type a new name in the Name text box (Figure 65-2).


        5. Specifying Whether an Object Can Be Created

          You can control whether or not a simulation object is listed on an object creation palette. It may not make sense to be able to create some types of simulation objects, such as missiles, which are normally added to a scenario and removed dynamically.

          To enable or disable creation of a simulation object from the Simulation Objects Palette, select or clear the Can Create Object check box (Figure 65-5).


          image

          Figure 65-5. Can Create Object check box


        6. Specifying the Object Creation Palette

          You can specify which of the object creation palettes an object should be listed on.

          To specify the object creation palette for an object:

          1. Select the object in the objects list.

          2. In the Palette list (Figure 65-5), select the palette you want to put it on.


        7. Specifying the Default Overlay

          When an object gets created, it gets placed on an overlay. By default, the object is placed on an overlay that has the same name as the object creation palette from which it is created. You can create additional default overlays and assign them to objects. You can still assign the object to a different overlay when it gets created. For details about over- lays and assigning objects to them, please see “Creating and Editing Overlays,” on page 38-2 and “Specifying an Object’s Properties Before You Create It (Click to Locate),” on page 16-13.

          To specify the default overlay:

          1. Select the object in the objects list.

          2. Select an option from the Default Overlay list (Figure 65-5).


            Adding a Default Overlay

            The default option for specifying the default overlay is to use the name of the object creation palette for the object. You can add overlays to use as the default overlay.

            To add a default overlay:

            1. Choose Edit Default Overlay Layers. The Overlay Layers dialog box opens.

            2. Click Add. The New Overlay Layer dialog box opens.

            3. Type a name for the layer.

            4. Click OK. The layer is added to the list in the Overlay Layers window.

            5. Click OK. The overlay is now available in the Default Overlay list.


        8. Specifying the Platform

          You cannot change the platform for existing simulation objects or new objects created from existing models. You can only specify the platform for new models that are not created from existing models. For details, please see “Creating a New Simulation Object,” on page 65-32.


        9. Undoing (Reverting) Changes to an Object

          If you have made changes to an object and have not yet saved the simulation model set, you can revert to the original simulation object configuration. You can revert an object at any time prior to saving the SMS, regardless of how many other objects you may have changed since you edited the simulation object you want to revert.

          To undo changes to an object:

          1. Select the object in the object list.

          2. Choose Model Revert Model.


      1. Editing Parameters that are Specific to Simulation Objects

        This section explains how to edit parameters that are only applicable to simulation objects and cultural features. (Cultural features are objects that you can add to a scenario to simulate human artifacts such as buildings, bridges, and so on. They are modeled as simulation objects because they exist in the physical world.)


        1. Editing a Simulation Object’s Used By Countries List

          The country code in a vehicle’s entity enumeration specifies the country in which the vehicle is manufactured. It does not indicate where the vehicle is used, and many vehicle types are used in multiple countries. When creating a scenario, it can be conve- nient if the Simulation Objects Palette only lists the vehicles used by the country for which you are laying down forces. The Used By Countries list in the Simulation Object Editor lets you specify the countries that use a vehicle. You can then filter the Simula- tion Objects Palette by country.

          You can also apply a country to humans and cultural features if they are specific to a country.

          The Used By Countries list works exactly like the Categories list. For details about how to configure the list of countries, please see “Editing the Category List,” on page 64-19.

          To assign a simulation object to a country of use, in the Used by Countries list (Figure 65-1), select the check boxes for the countries that use it.


          Clearing the Used By Countries List

          If you add a new model by copying another model, you may want to quickly clear the Used By Countries list before selecting the countries for the new model. (You can clear the other lists the same way.)

          image

          To clear the Used by Countries list, click the Clear button ( ) at the top of the list.


        2. Editing a Simulation Object’s Bounding Volume (Size)

          VR-Forces uses a simulation object’s bounding volume to do intersection tests. The bounding volume is specified by the values in the Size group box. You can display a simulation object’s bounding volume in the Visual Model group box. If you change size values, the bounding volume changes accordingly.

          You can set the bounding volume in the following ways:

          • Edit the value manually.

          • Calculate the bounding volume of a particular entity based on the model.

          • Calculate the bounding volumes for all entities based on their models.


            image

            i

            i

            • The bounding volume is not the same thing as the selection box that is displayed around a simulation object when you select it. The selection box is just part of the front-end display. The bounding volume is used by the simulation engine.

            • You can exclude individual entities from the global updates.

            • VR-Forces calculates the bounding volume for units based on the loca- tions and bounding volumes of the members of the unit.


              image


              To change an entity’s bounding volume manually:

              1. Select the entity you want to edit in the object list.

              2. Change any of the values in the Size group box (Figure 65-6).


              image

              Figure 65-6. Size group box

              image

              To calculate the bounding volume of an entity from its model, click the Calculate Support Points and Bounding Volume from Displayed Model button image) or the Calculate Bounding Volume from Displayed Model button ( ).


              To calculate the bounding volume for all entities, choose Model Compute Bounding Volume and Support Points.


        3. Displaying a Simulation Object’s Bounding Volume


          image

          i

          i

          You must run VR-Forces at least once before you can display bounding volumes in the Simulation Object Editor.


          image


          To display a simulation object’s bounding volume:

          1. Select the entity in the object list.

          2. In the Visual Model group box, on the Model Sets list, select 3D Models.

          3. Select the Bounding Volume check box. The bounding volume is displayed (Figure 65-7).


          image

          Figure 65-7. Bounding volume


        4. Specifying Support Points

          Support points are the locations on a model that contact the ground. You can specify support points in any of the following ways:

          • Set them manually.

          • Calculate them from the 3D model.

          • Calculate the support points for all entities based on their models.

            To specify support points manually, in the Size group box (Figure 65-6), type the desired values.

            image

            To calculate support points based on the model, in the Size group box, click the Calculate Support Points and Bounding Volume from Displayed Model button ( ) or the Calculate Support Points from Displayed Model button image).

            To calculate the support points for all entities, choose Model Compute Bounding Volume and Support Points.


        5. Excluding Entities from Batch Bounding Volume and Support Point Updates

          If you run the Compute Bounding Volume and Support Points command, it updates all entities. If you have specified the bounding volume or support points for an entity manually, this operation might override those settings. You can exclude individual enti- ties from the global update process.

          To exclude an entity from the global update process:

          1. Select the entity in the object list.

          2. In the Size group box, select the Exclude From Batch Update check box.


        6. Editing Behavioral Parameters

          The Simulation Object Editor lets you edit some of the parameters that affect simula- tion object behavior. For detailed information about these parameters, please see the parameter descriptions in the OPD Editor online help.


          image

          i

          i

          The Sensor Signature parameters specify the distance at which other simulation objects can sense the simulation object you are editing. By contrast, the sensor systems on the simulation object control its ability to sense other simulation objects. For more information, please see “Editing a Simulation Object’s Systems,” on page 65-28.


          image

          To edit simulation object parameters, edit any of the parameters in the Attributes panel (Figure 65-8). (The panel reconfigures itself as you select different types of simulation objects.)


          image

          image

          image

          Size


          Movement


          image

          Sensor Signature


          Figure 65-8. Attributes panel


        7. Adding Object Geometry to an Entity

          Object geometry is to an entity as terrain is to the earth. It allows embarked entities to move about on the entity on which they are embarked. For example, adding object geometry to an aircraft carrier lets planes taxi on the deck of the carrier. You can add object geometry to entities in the Simulation Object Editor. Object geometry must be in OpenFlight, MEDF, or GDB format. OpenFlight geometry gets converted to GDB and saved. For complete details about adding object geometry and generating naviga- tion data, please see “Generating Navigation Data for Entities,” on page 58-9.


          image

          i

          i

          When you edit an entity’s embarkation points and slots, the model used is the visual model. This will not necessarily line up with the object geometry for that entity, if it has any.


          image


          To add object geometry to an entity:

          1. Select the entity in the Object List.

          2. In the Movement group box (Figure 65-8), select Use Detailed Geometry in Simu- lation Engine.

          3. Click Select. The Select Object Geometry dialog box opens.

          4. Click the Browse button. The Object Geometry dialog box opens.

          5. Select the file that contains the object geometry for this entity.

          6. Click Open.

          7. Click OK.


        8. Ground Clamping Cultural Features

          You can specify that cultural features be aligned to the terrain (ground clamped). If they are not aligned to the terrain they might end up sticking out at odd angles.


          image

          Figure 65-9. Is Gravity Aligned check box

          To align cultural features to the terrain, select the Is Gravity Aligned check box (Figure 65-9).


        9. Editing a Lifeform’s Visual Model and Animation

    VR-Forces can specify the character, appearance, hand item, head, and animation values for DI-Guy models used in the 3D view and visualization applications such as VR-Vantage. A model’s character determines the kinds of movement it can make. The appearance determines what it looks like. The animation specifies the movements that the character makes. In the VR-Forces front-end, you can specify the animation with the DI-Guy Animation task. You can set the appearance with the DI-Guy Appearance set data request. This feature is valid only for lifeforms (the Human and Animal catego- ries).

    To specify the default DI-Guy characteristics for a lifeform:

    1. In the Categories list, select the Human or Animal category.

    2. Select a lifeform in the object list.

    3. In the Visual Model group box, on the Model Sets list, if 3D Models is not selected, select it.

    4. In the Visual Model group box, click Edit. The Modify Visuals dialog box opens (Figure 65-10). The Use DI-Guy option should be selected. If it is not selected, select it.



      image

      Figure 65-10. DI-Guy Character group box

    5. Optionally, filter the options available in the lists, as follows:

      1. Click Filter. The DI-Guy Filters dialog box opens.

      2. Select an option for each characteristic that you want to filter on.

      3. Click OK.

    6. Select the DI-Guy character you want to use from the Character Type list.

    7. Select the default appearance from the Default Appearance list. One of the default options is to use a random appearance.


    8. If you selected random appearance, optionally, specify the list of appearances to choose from. For details, please see “Configuring the Random DI-Guy Character- istics Lists,” on page 65-17.

    9. Optionally, in the Default Hand Item list, select a hand item. If you choose random, click Random Hand Item List to specify the hand items that can be chosen.

    10. Optionally, in the Default Head list, select a head. If you select random, you can specify the list of heads to choose from. If you choose random, click Random Head List to specify the heads that can be chosen.

    11. Select the default animation from the Default Animation list. The default anima- tion is the animation the entity uses if it is not tasked and if it has a posture and speed that is appropriate to the animation.


    Configuring the Random DI-Guy Characteristics Lists

    When you configure the visual model for a DI-Guy, you can specify that a lifeform use a random appearance, hand item, head, or some combination of these. When VR- Forces creates a lifeform, it chooses from the random characteristic lists. By default, a random list has all options available for the chosen character. However, you can specify a subset of the available characteristics to use.

    To configure the DI-Guy characteristics lists:

    1. In the Categories list, select the Human category (or Animal category).

    2. Select a lifeform in the object list.

    3. In the Visual Model group box, on the Model Sets list, if 3D Models is not selected, select it.

    4. In the Visual Model group box, click Edit. The Modify Visuals dialog box opens (Figure 65-10). The Use DI-Guy option should be selected. If it is not selected, select it.

    5. Click the random list button for the characteristic you want to configure. A dialog box opens (Figure 65-11). The options available for the character type are listed.

    6. Optionally, filter the list by selecting options in the filter lists.



      image

      Figure 65-11. Random Appearances List dialog box

    7. Select the options that you want to include in the random list.

    8. Clear any options that you do not want to include in the random list.

    9. Click OK.

    10. Click OK to close the Modify Visuals dialog box.


      1. Editing a Simulation Object’s Visual Model

        The Visual Model Editors dialog box allows you to configure all aspects of entity visual- ization, including the 2D icon and 3D model used. (For details, please see Chapter 81, Model and Element Definitions.) However, the Simulation Object Editor lets you quickly and easily change the 3D model or 2D icon used to represent a simulation object. When you change a model in the Simulation Object Editor, the entity’s model definition also gets changed.

        To change the visual model for a simulation object:

        1. In the object list, select the object list whose model you want to change. The model for the currently selected model set is displayed in the Visual Model group box.


          image

          i

          i

          The visual model window responds to the same keyboard and mouse controls as the front-end.


          image


        2. In the Model Set list in the Visual Model group box, select the model set that you want to edit for this simulation object.

        3. Optionally, select a visual type in the Visual Type list. This choice changes the 3D model for any simulation object that is using a generic model. If a simulation object has a specific model, changing the visual type does not affect it.

        4. Change the 3D model, 2D icon, or 2D image as described in the following sections.


        1. Changing the 3D Model or Colorized Model

          To change a 3D model or 3D colorized model:

          1. Click Edit. The Modify Visuals dialog box opens (Figure 65-12).

          2. If the dialog box has options for 3D Models or DI-Guy, select Use 3D Model. The Modify Visuals dialog box lists available models (Figure 65-12). (You can add new models. For details, please see “Adding a New Visual Model or Image,” on

            page 65-24.)


            image

            Figure 65-12. Modify Visuals dialog box (3D)

          3. Select the model that you want to use. The new model is displayed in the panel.


            image

            i

            i

            By default, the Modify Visuals dialog box tries to filter the list to show only the type of entity that you are editing. If you do not see the models you expect to see in the list, particularly if you know that the models are available in the ./data directory, try changing the filter. For example, surface entities are of type Watercraft, while subsurface entities are of type Entity.


            image


          4. Click OK to close the Modify Visuals dialog box.


        2. Changing the 2D Icon Using a Font

          To change a 2D icon using the MIL-STD font:

          1. Be sure that the Edit Spot Report Models check box is cleared.

          2. Select the simulation object whose icon you want to edit.

          3. In the Visual Models group box, in the Model Sets list, select 2D Icons.

          4. Click Edit. The Modify Visuals dialog box opens (Figure 65-13).


            image

            Figure 65-13. Modify Visuals dialog box (2D)

          5. Select the Use MIL-STD Font option. The dialog box lists index values and associ- ated glyphs.

          6. Select the icon glyph that you want to use. The new icon is displayed in the panel

          7. Click OK to close the Modify Visuals dialog box.


            Regenerating Spot Report Definitions

            When you change the 2D icon for a simulation object, the spot report icon for that object does not change. You can change the icon manually, as described in “Editing a Spot Report Icon,” on page 65-23, or you can automatically update spot report defini- tions.

            To regenerate spot report definitions:

            1. Choose File Regenerate Spot Report Definitions. A prompt opens.

            2. Click Yes.


        3. Changing the 2D Icon Using an Image

          To change a 2D icon using an image:

          1. Be sure that the Edit Spot Report Models check box is cleared.

          2. Select the simulation object whose icon you want to edit.


          3. In the Visual Models group box, in the Model Sets list, select 2D Icons.

          4. Click Edit. The Modify Visuals dialog box opens (Figure 65-13).

          5. Select the Use Image option. The dialog box lists the forces that are configured for this simulation model set (Figure 65-14).


            image

            Figure 65-14. Modify Visuals dialog box (2D image)

          6. Click the Edit button for the force whose icon you want to change, or to choose the same image for all forces, click Select for All. The Select Model Definition dialog box opens (Figure 65-15). It lists the available images. By default the list is for MIL-STD 2525a icons. (You can add new images. For details, please see “Adding a New Visual Model or Image,” on page 65-24.)


            image

            Figure 65-15. Select Model Definition dialog box

          7. Select the image that you want to use. The new image is displayed in the panel.

          8. Click OK.

          9. Click OK to close the Modify Visuals dialog box.


        4. Editing a Spot Report Icon

          You can edit the icon that is used when a spot report is at the full knowledge level. (The icons used at the detected, classified, and identified levels are not editable.)


          image

          i

          i

          When the Edit Spot Report Models check box is selected, you can only edit spot report icons. To edit any other visual model, clear the check box.


          image


          To edit a spot report icon:

          1. In the Visual Models group box, select the Edit Spot Report Models check box. If the model set is not already 2D Icons, it changes to 2D Icons and the window shows the icons for this simulation object.

          2. Click Edit. The Modify Visuals dialog box opens (Figure 65-13).

          3. Follow the directions for changing a 2D icon, as described in “Changing the 2D Icon Using a Font,” on page 65-21 or “Changing the 2D Icon Using an Image,” on page 65-21Changing the 2D Icon Using a Font or Changing the 2D Icon Using an Image.


        5. Adding a New Visual Model or Image

          When you change a model or image in the Simulation Object Editor, you are presented with a list of the currently configured model definitions or images. You can add addi- tional models to the list. You can add new model definitions in the context of editing a simulation object or independently of editing a simulation object. If you edit the list in the context of editing a simulation object, you can also add images to the list.


          Adding A Model Definition while Editing a Simulation Object

          To add a new model or image to the visual models list while editing a simulation object:

          1. In the object list, select the object whose model you want to change. The model for the currently selected model set is displayed in the Visual Model group box.

          2. In the Visual Model group box, in the Model Sets list, select the model set that you want to edit.

          3. For 3D models or 3D colorized models:

            1. Click Edit. The Modify Visuals dialog box opens (Figure 65-12).

              image

            2. Click the Add button ( ). The Model Definition dialog box opens. This is a standard file chooser dialog box.

              For 2D icons, do the following:

              1. Click Edit. The Modify Visuals dialog box opens (Figure 65-13).

              2. Select the Use Image option. The dialog box lists the forces that are configured for this simulation model set.

              3. Click the Edit button for the force to which you want to add an image. The Select Model Definition dialog box opens (Figure 65-14).

          4. Select the file for the model that you want to add to the list. It must be a model or image type that VR-Forces supports. (This file becomes the value for the filename attribute of the model definition.)

          5. Click OK. The Model Definition Name dialog box opens.

          6. Type a name for the model definition.

          7. Click OK.

          8. Click OK to close the Modify Visuals dialog box.


            Adding Model Definitions Independently of Editing a Simulation Object

            You can add model definitions in the Simulation Object Editor independently of any simulation object just as you can in the Visual Model Editors dialog box. The only attribute that you can set is the filename. However, in many cases that is the only attri- bute you need. If you need to specify other attributes, you must use the Visual Model Editors dialog box.

            To add a model definition independently of editing a simulation object:

            1. Choose Edit Add Model Definition. The Add Model Definition dialog box opens.

              image

            2. Click the Add button ( ). The Model Definition dialog box opens. This is a stan- dard file chooser dialog box.

            3. Select the file for the model that you want to add to the list. It must be a model or image type that VR-Forces supports. (This file becomes the value for the filename attribute.)

            4. Click OK. The Model Definition Name dialog box opens.

            5. Type a name for the model definition.

            6. Click OK. The new model definition is added to the list.

            7. Click OK to close the Add Model Definition dialog box.


        6. Displaying Details about the Visual Model

          The Visual Model group box displays the model used for the selected simulation object. Using the lists and check boxes, you can change how the model is displayed and show information about it, as follows:


        7. Importing Visual Models

          You can import visual models (element definitions, model definitions, and object type mappings) into an SMS. You might want to do this if you have edited an SMS and then decide that you need to revert to a previous version that you have saved in ./factory or elsewhere. When you import visual models, the imported model definitions replace any matching definitions in the SMS. The import operation imports all leaf files in the selected directory.

          To import visual models:

          1. Choose File Import Visual Models. A confirmation prompt opens.

          2. Click Yes. A file chooser dialog box opens.

          3. Select the directory from which you want to import visual models.

          4. Click Choose.


        8. Pruning Visual Models

          Pruning visual models (element definitions, model definitions, and object type mappings) removes duplicate visual models from the set of leaf files that get loaded for an SMS. This improves the load time in the SOE and when you load a scenario.

          Pruning only affects the SMS-specific definitions files. It does not touch any additional definition files that may have been saved from the Visual Model Editors dialog box.

          To prune visual models:

          1. Choose File Prune Visual Models. A confirmation prompt opens.

          2. Click Yes. A file chooser dialog box opens.

          3. Select the directory from which you want to import visual models.

          4. Click Choose.


        9. Exporting Visual Models

          When you update an SMS, you can export the visual models (element definitions, model definitions, and object type mappings) to a directory other than the default directory in the SMS. This would typically be done for archival purposes, such as updating the files in ./factory.

          Only the SMS-specific definitions files get exported. If user-created leaf files were previ- ously loaded, the definitions do not get exported back to those leaf files. They get included in the SMS-specific files.

          To export visual models:

          1. Choose File Export Visual Models. A confirmation prompt opens.

          2. Click Yes. A file chooser dialog box opens.

          3. Select the directory to which you want to export visual models.

          4. Click Choose.


        10. Reloading Visual Models in the VR-Forces GUI

    If you update the visual models associated with simulation objects and you have a scenario open, you can refresh the models used in the scenario without shutting down VR-Forces.

    To refresh visual models, choose Settings Reload Visuals.


      1. Editing a Simulation Object’s Systems

        Simulation objects have complex capabilities, such as the ability to move, to take damage, to sense other simulation objects, and to fire munitions. These capabilities are organized as systems. You can quickly change how a simulation object functions by adding, removing, and changing its systems. The Simulation Object Editor lists the systems available in each category and only lists systems that are appropriate for the entity type (Figure 65-16). For example, a lifeform can have an M-16 or an RPG, but not a cruise missile.



        image

        Add System Remove System Edit Properties Open OPD Editor


        Figure 65-16. Entity systems

        Some systems are interdependent. For example, if you add a weapon system to a simu- lation object, it probably cannot use it unless it also has a sensor system so that it can detect simulation objects. If you change or add systems, it is up to you to know if they have dependencies.

        The components that make up a system have parameters and you can edit the parame- ters of system components by editing the properties of the system.


        The Simulation Object Editor lets you edit the following types of systems:


        1. Adding a System

          There is no specific limit to the number of sensors, weapons, or other systems that you can configure for a simulation object.

          To add a system:

          1. Click the Add System button image) for the system type you want to add. The Add System dialog box opens (Figure 65-17). It lists the systems of this type that are available for the simulation object you are editing. If you select a system in the window, the dialog box displays a brief description.


            image

            Figure 65-17. Add System dialog box

          2. Select the system you want to add.

          3. Click OK. The system is added to the list in the Simulation Object Editor.


        2. Selecting a Damage Model

          You can only have one damage model specified for a simulation object.

          To specify a damage model, select an option from the Damage list.


        3. Selecting a Movement Model

          You can only have one movement model specified for a simulation object.

          To specify a movement model, in the Movement group box, select an option from the Movement Dynamics list.


        4. Editing a System’s Properties

          Some systems have properties that you can edit.

          To edit a system’s properties:

          1. Select the simulation object whose system you want to edit.

          2. For sensors, weapons, or other systems, select the system whose properties you want to edit. (You do not have to select the damage or movement model, because there can only be one.) If the system has properties, the Properties button is enabled.

          3. Click the Edit Properties button image). A Properties dialog box opens. The 3D model in the Visual Models group box displays a green dot on the simulation object where the system is located. In some cases there are multiple locations.

            Optionally, in the Visual Models group box, select the Marker Labels check box. A label is added to the green dot to identify it.

          4. Edit the properties as desired.

          5. Click OK.


        5. Editing a System in the OPD Editor

          Systems may have attributes that you cannot edit in the Simulation Object Editor. You can jump directly to the OPD Editor from the Simulation Object Editor to edit these attributes. When you open the OPD Editor from the Simulation Object Editor, only the Systems page is displayed. You cannot edit other attributes.


          image

          !

          !

          Before you jump to the OPD Editor, save any changes that you have made to the simulation model set. If you make any changes in the OPD Editor, the Simulation Object Editor is automatically updated after you save the changes in the OPD Editor.


          image


          To jump to a system in the OPD Editor:

          1. Save your changes to the SMS.

          2. Select the system that you want to edit.

            image

          3. Click the Open OPD Editor button ( ) next to the system.

            Editing Simulation Object Models — Creating a New Simulation Object

            image

        6. Removing a System

          You can remove sensor, weapon, and additional systems.


          image

          i

          i

          If you remove a system that another system depends on, the other system will not work. It is your responsibility to know these dependencies.


          image


          To remove a system:

          1. Select the system you want to remove.

          2. Click the Remove System button image).


      1. Creating a New Simulation Object

        You can create a new simulation object by using an existing object as a template or by building a completely new object.


        image

        i

        i

        The procedure for creating a new unit is largely the same as for creating a new entity. The main difference is that units do not have 3D models and when you create a unit, you specify its subordinates.


        image


        To create a completely new entity:

        1. Choose Model New Model. The Create New Entity dialog box opens (Figure 65-18).


          image

          Figure 65-18. Create New Entity dialog box

        2. Select a platform type.

        3. Optionally, select a template. (Templates are specific to a platform type. There might not be a template for some platforms.)

        4. Type a name for the entity.

          Editing Simulation Object Models — Creating a New Simulation Object

          image


        5. Optionally, click Edit and specify the object type. You can do this after you create the entity if you want to. You can also just accept the object type supplied by VR- Forces.

        6. Click OK. The Simulation Object Editor adds a new entry to the object list. The editor shows default values for all the fields.

        7. Optionally, edit the enumeration.

        8. Optionally, specify that this entity is a favorite.

        9. Specify 2D and 3D visual models.

        10. Specify appropriate values for the entity parameters.

        11. Type a name to be used in the entity’s label (marking text) in the Short Name text box.

        12. Specify a movement system.

        13. Specify a damage model.

        14. Optionally, add weapon systems.

        15. Optionally, add sensors.

        16. Save the simulation model set.


          65.5.1. Creating a New Model from an Existing Model

          If you create a new simulation object model from an existing model, the new model starts with all of the behavioral characteristics and systems of the original one. It incre- ments the object enumeration. You just have to name it and customize it for the new simulation object.


          image

          i You can use this procedure to create new units.

          image

          Editing Simulation Object Models — Deleting an Object Model

          image


          To create a new simulation object model from an existing model:

          1. In the object list, select the source object.

          2. Choose Model New Model from Existing. The Create New Model dialog box opens.

          3. Type a name for the model.

          4. Optionally, edit the enumeration.

          5. Click OK. The new simulation object is added to the object list. If you did not edit the enumeration, the original enumeration is incremented. A .entity file is created based on the name.

          6. Edit the parameters to provide the new simulation object the characteristics you want for it.

          7. Save the simulation model set.


      2. Deleting an Object Model

        To delete an object model from a simulation model set:

        1. Select the object in the object list. (You can select multiple models using the Shift

          or Ctrl keys.)

        2. Choose Model Delete Model or press Delete.


      3. Configuring Embarkation

        If an entity allows other entities to embark on it, you can configure:

        • Allowed entity types. The types of entities that can embark.

        • Slots. The location on an entity where embarked entities move to. The number of slots on an entity controls how many entities can embark on it using the Embark task. For entities that are visible when they are embarked, such as humans on a truck or aircraft on an aircraft carrier, it is important to specify sensible looking slots.

          Slots can have a type and a name. Use of slot types and names allows you to tell a simulation object to embark in a specific slot.

        • Ingress points. The locations on an entity where entities embark before moving to a slot.

        • Egress points. The locations on an entity from which entities disembark.


        image

        i

        i

        Units can support embarkation, but the usual use of embarkation is for entities to embark on other entities. In entity-level scenarios, if a unit embarks, the individual members of the unit carry out the embarkation task.


        image


        To configure embarkation for an entity:

        1. In the Simulation Object Editor object list, select the entity that you want to configure embarkation for.

        2. In the Attributes panel, if Can Be Embarked Upon is not selected, select it.

        3. Optionally, select Can Be Moved Onto For Embark. This option lets ground- clamped entities identify entities that they can embark on. They can then walk or drive onto the entity and automatically become embarked.

        4. Click Configure. The Configure Embarkation dialog box opens (Figure 65-19).


          image


          Figure 65-19. Configure Embarkation dialog box

        5. Click Add. The Add Type dialog box opens.

        6. Select a type of entity that can embark.

        7. Optionally, add additional entity types.

        8. For each entity type listed, specify ingress and egress points. Values are in meters relative to the center of the parent entity. For more information, please see “Adding Ingress and Egress Points,” on page 65-36.


        9. Optionally, configure slots. For more information, please see “Configuring Slots,” on page 65-38.

        10. Click OK.


        1. Adding Ingress and Egress Points

          An ingress point specifies where an entity embarks onto another entity. An ingress point can specify a path that the entity follows to get to the ingress point and how it moves once it is on the entity. For example, a jet embarking on an aircraft carrier can taxi to its slot.

          An egress point specifies where an entity disembarks from the parent entity.

          You can specify that an ingress point should only support some of the slots on the entity. You might want some types of entities embarking at one ingress point and moving to certain slots, while other entities embark at a different location and use other slots. For example, if you are simulating a ferry, cars and trucks would enter at the front or rear and move below deck. Foot passengers would enter at the sides and move to the passenger decks.

          When you add an allowed entity type, the Simulation Object Editor automatically creates a slot for that entity type. The ingress and egress points that you configure for that entity type on the basic version of the Configure Embarkation dialog box are auto- matically associated with the same slot.

          In Advanced mode, you can add additional ingress and egress points and associate them with whichever slot you want. You do not have to add them in pairs.


          image

          i

          i

          This procedure describes configuring an ingress point. To configure an egress point, substitute egress for ingress in each step.


          image


          To add an ingress point:

          1. In the Simulation Object Editor object list, select the entity that you want to configure embarkation for.

          2. Click Configure. The Configure Embarkation dialog box opens (Figure 65-19).

          3. Click Advanced. The dialog box redisplays.

            image

          4. Click the Add button ( ) above the Ingress Points list. An ingress point is added to the list. A vertex is added to the display window at the center of the entity bounding volume (Figure 65-20). The coordinates for the ingress point are displayed at the bottom of the dialog box.



            image

            Figure 65-20. Ingress Point

          5. Double click the X value for the Ingress point to make it editable.

          6. Enter the X value.

          7. Repeat for the Y and Z values.

          8. If you want to specify a path for the embarking entity

            1. Click the Add button for the Ingress Point coordinates list. A new coordinate is added.

            2. Specify the X, Y, and Z values for the new coordinate. The path is displayed in the window (Figure 65-21).


              image

              Figure 65-21. Ingress point configuration

          9. Optionally in the Supported Slots field, type the numbers for the slots that should support this ingress point. If you leave the field blank, it supports all slots. If you specify more than one slot, separate the numbers with space.

          10. To change the side of a parent simulation object that the embarked simulation objects exit on, select the Flip Disembark Body X check box, the Flip Disembark Body Y check box, or both (Figure 65-22).

          11. Click OK.


        2. Configuring Slots

          The Simulation Object Editor adds a slot to the embarkation configuration for each allowable object type that you add. The slot is configured with the object type of the allowable object type. You can configure several parameters for the slots. You can add and remove slots with the Add and Remove buttons.

          To configure slots:

          1. In the Simulation Object Editor object list, select the simulation object that you want to configure embarkation for.

          2. Click Configure. The Configure Embarkation dialog box opens (Figure 65-19).

          3. Click Advanced. The dialog box redisplays.

          4. Select the slot that you want to edit. The dialog box redisplays to show the slot’s parameters (Figure 65-22).


            image

            Figure 65-22. Slot parameters

          5. Optionally, configure Slot Exclusions. For details, please see “Configuring Slot Exclusions,” on page 65-40.

          6. To change the side of a parent simulation object that the embarked simulation objects exit on, select the Flip Disembark Body X check box, the Flip Disembark Body X check box, or both.

          7. If you have added a new slot, in the Object Type field, specify the object enumera- tion for the type of simulation object that can use this slot. If this is a previously created slot, you can edit the object type. You can configure different object types in different slots on a simulation object.

          8. If you want to give the slot a name, type it in the Slot Name text box.

          9. If you want to categorize this slot as a specific named type (a text string, not an object type enumeration), type it in the Slot Type text box.

          10. In the Position group box, specify the location of the slot relative to the center of the entity’s bounding volume.


          11. In the Orientation group box, specify the orientation of the slot relative to the center of the entity.

          12. Click Change Appearance and specify the appearance of the simulation object type when it is in the slot. For example, a human embarked on a truck might have its posture set to Sitting.

          13. If you want the embarked simulation object to immediately jump to the slot, select Jump To Location. If this check box is clear, the simulation object will move to the slot. For example, an aircraft will taxi to a slot on a carrier deck.

          14. If you want the embarked simulation object to have the same heading as the parent entity, select Turn To Heading.

          15. If you want the embarked simulation object to be invisible in 3D observer modes, select Invisible When Embarked.

          16. Specify the number of entities that can use this slot.


    Configuring Slot Exclusions

    A slot exclusion specifies that if a given slot is occupied, other slots cannot be occupied. For example, an entity might allow both tanks and dismounted infantry entities to embark. If no tanks are embarked, the entity can hold 20 DIs. But if a tank is embarked, it uses up 10 slots and now only 10 DIs can embark.

    To configure slot exclusions:

    1. On the Slot Exclusions line, click Edit. The Edit Slot Exclusions dialog box opens (Figure 65-23).


      image

      Figure 65-23. Edit Slot Exclusions dialog box

      image

    2. Click the Add button ( ). A blank line is added to the list.

    3. Double-click the cell in the Slot Is Filled column. The cell becomes editable.

    4. Type the number of the slot that you want to configure.

    5. Double-click the cell in the Exclude Slots column.

      Editing Simulation Object Models — Configuring Wakes

      image


    6. Type the numbers of the slots that cannot accept entities if the slot you are config- uring is filled. You can enter more than one slot to be excluded. Separate the slot numbers with a space.

    7. Repeat this procedure to add additional exclusions. You can also edit existing exclu- sions and delete them.


      1. Configuring Wakes

        You can configure the wake parameters for surface entities in the Simulation Object Editor. The model window shows the ocean state and you can vary the wind speed, entity speed, and choppiness to see how the wake looks under varying ocean conditions (Figure 65-24).


        image

        Figure 65-24. Wake display

        Editing Simulation Object Models — Configuring Wakes

        image


        To configure wakes:

        1. Select a surface entity in the object list.

        2. Click the Edit button next to the Wake Model label. The Edit Wake Model dialog box opens (Figure 65-25).


          image

          Figure 65-25. Edit Wake Model dialog box

        3. Change wake parameter values as desired. For details about wake parameters, please see “Configuring Wakes,” on page 83-14.

        4. To see the effect of parameter changes under different sea conditions:

          1. Choose Edit Ocean Settings. The Ocean Settings dialog box opens.

          2. Adjust the wind speed, wind direction, and choppiness values.

          3. Click OK.

        5. Click OK.

          Editing Simulation Object Models — Creating Randomized Simulation Objects

          image

      2. Creating Randomized Simulation Objects

        A randomized simulation object is an object that you can use to quickly add a generic simulation object type, such as a civilian vehicle or commercial aircraft, using randomly chosen specific models of these object types. For example, if you want to add several cars to a scenario, you could individually select a Nissan Maxima, a Toyota Corolla, a Honda Accord, and so on, and add them to the scenario. Or you could select a random- ized simulation object that references a list of civilian vehicles and click multiple times on the terrain, With each click a randomly chosen vehicle would be added to the scenario.

        You create randomized simulation objects in the Simulation Object Editor. You can create them in entity-level and aggregate-level scenarios.

        To create a randomized simulation object:

        1. Start the Simulation Object Editor.

        2. Load the SMS you want to use.

        3. Choose Model New Randomized Simulation Object. The Randomized Simulation Object dialog box opens.

        4. Type a name for the simulation object. The new object is added to the object list.

        5. Select the new object in the object list (Figure 65-26).


          image

          Figure 65-26. Randomized simulation object

        6. Optionally, edit the common simulation object attributes, such as category, palette, default overlay, and so on.

        7. Click the Add button (Figure 65-26). The Add to Randomized Simulation Object dialog box opens.

          Editing Simulation Object Models — Creating Randomized Simulation Objects

          image


        8. Select the simulation objects that you want to be part of this randomized simula- tion objects. To select an object, double-click it or select it and click Add. As you select objects, they are added to the list (Figure 65-27). If you want the probability of a particular simulation object being created to be higher than others, add multiple instances of the same simulation object to the list.


          image


          Figure 65-27. Randomized object list

        9. Click Close.

        10. Save the SMS.

          Editing Simulation Object Models — Creating a Simulation Object Group

          image

      3. Creating a Simulation Object Group

        You create simulation object groups (SOGs) in the Simulation Object Editor. You specify the members of the SOG in a version of VR-Forces that gets launched from the Simulation Object Editor. When the Simulation Object Editor launches VR-Forces, it needs to use a simulation connection. For details about setting the simulation connec- tion, please see “Setting the Simulation Connection when Creating an SOG,” on

        page 65-46.

        Simulation objects groups are saved with the extension .sog.

        To create a simulation object group:

        1. Start the Simulation Object Editor.

        2. Load the SMS you want to use.

        3. Choose Model New Object Group. The New Object Group dialog box opens.

        4. Type a name for the new SOG.

        5. Click OK. The new group is added to the objects list and the Simulation Object Editor displays a simulation object group page.

        6. Specify the category, creation palette option, and other generic information as you would for any simulation object.

        7. Optionally change Creation Options and the altitude offset.

        8. Click Launch Object Group Editor. You are prompted to save your changes to the SMS.

        9. Click Yes. A limited version of VR-Forces opens. It has a green terrain grid.

        10. Use the object creation palettes to add objects to the SOG as you would for a scenario. You can change to Stealth observer mode if you want to view the terrain in 3D. It is a flat terrain.


          image

          i

          i

          When you add objects to an SOG, they are placed on overlays, just as when you add objects to a scenario. There may be cases where you add tactical graphics to an SOG, but do not want them to be displayed when you place the SOG in a scenario. For example, you might put routes on the deck of an aircraft carrier, but do not want to clutter up the display with them. If you edit the name of the tactical graphics overlay and put an asterisk (*) in front of the name, when the SOG is placed, the overlay will be hidden. For more information, please see “Hiding an Overlay by Default,” on page 38-4.


          image


        11. Choose File Save Object Group to save the SOG and continue editing. Choose

    File Save Object Group and Exit to save the SOG and close VR-Forces.

    Editing Simulation Object Models — Navigating Among Edited Simulation Objects

    image

        1. Setting the Simulation Connection when Creating an SOG

          When you create an SOG, the Simulation Object Editor starts VR-Forces so that you can specify the members of the SOG. By default it uses the DIS localhost connection for EntityLevel.sms and the HLA 1516 Evolved RPR 2.0 with MAK extensions connec- tion for AggregateLevel.sms. You can change the connection if you want to.

          To set the simulation connection when specifying the members of a simulation object group:

          1. In the Simulation Object Editor, choose Edit Object Group Connection. The Choose Connection dialog box opens.

          2. Select the connection you want to use.

          3. Click OK.


      1. Navigating Among Edited Simulation Objects

        If you have viewed or edited several simulation objects and want to return to a previous object without finding it in the simulation objects list, you can use the Forward and Backward arrows to navigate among previously edited simulation objects. The arrows act like the forward and back buttons in a web browser.


        image

        Figure 65-28. Forward and Back arrows


      2. Configuring Scripted Entity Movement

    In most cases, simulation objects move based on the intelligence built into their compo- nents – sensors, controllers, and actuators. However, there are two instances in which entity movement follows a predetermined sequence, or script. These cases are ballistic missile movement and animated movement tasks.

    When you launch a ballistic missile (by creating a missile target in VR-Forces), it does not follow a route or do any path planning; it flies based on the parameters in the scripts it is configured to use. Similarly, if you give an animated movement task to an entity, it moves in whatever way the script prescribes.

    Ballistic missile movement is configured using comma-delimited value (CSV) files. Animated movement tasks can be configured with CSV files or 3DS ASCII Export (ASE) files. We refer to these files generically as movement files.

    A movement file specifies a time sequence and a set of parameters that define the entity’s movement for each time entry. Ballistic missile movement files define lateral- distance, altitude, and range. Animated movement movement files define lateral distance, altitude, range, heading, pitch, and roll.


    image

    i

    i

    Ballistic missile movement files get configured in a dialog box that is shared with animated movement movement files (“Configuring Animated Movement,” on page 65-50). Animated movement movement files have more parameters than ballistic missile movement files. If a ballistic missile is configured with a movement file that has these additional parameters, they are ignored.


    image


        1. Configuring Ballistic Missile Movement

          When you create a Missile Target event in VR-Forces, you specify a missile type. Missile types are configured in the Simulation Object Editor.

          To configure ballistic missiles:

          1. Choose Edit Ballistic Missiles. The Ballistic Missiles dialog box opens (Figure 65-29).


            image

            Figure 65-29. Ballistic Missiles dialog box

            image

            image

            image

          2. In the Missile Type list, select the missile type that you want to edit. You can add, delete, and rename missile types using the Add ( ), Delete ( ), and Rename ( ) buttons.

          3. Optionally, in the Description text box, type a description. This description gets used as a tooltip for the Missile Type in the Create Missile Target (and Edit Missile Target) dialog boxes.

          4. In the Stages list, select the stage that you want to configure. Missiles can be single stage or multi-stage. For single stage missiles, configure Stage 1. For multi-stage missiles, use the Add and Delete buttons to add or delete stages.

            For each stage, specify the following:

            – Movement File. The CSV file to use. The list lists the files in ./data/simulation- ModelSets/<model_set>/scriptedObjectMovement. If you want to use a CSV file that is not listed:

            1. Click the Add button next to the Movement File list. A file chooser dialog box opens.


            2. Select the CSV file that you want to use. The file is copied to ./data/simula- tionModelSets/<model_set>/scriptedObjectMovement.

              image

              Table 65-1: Clamp type options


              Option Description

              Option Description

              None (Geodetic) Altitude in the animation is used as altitude above the alti-

              tude of the animation reference location. A constant alti- tude in the animation will result in a path that follows curvature of the earth, when a round earth terrain is being used.

              None (Topographic) Altitude in the animation is used as altitude above a plane

              defined by the animation reference orientation. A constant altitude in the animation will result in a straight path, even as the earth curves, when a round earth terrain is being used.

              High Fidelity (Including Orientation)


              Low Fidelity (Terrain Clamp Only)


              Altitude Above Terrain (High Fidelity)

              Ground Clamp if Altitude Offset is 0 (High Fidelity)

              Altitude in the animation is ignored, and the object is ground clamped to the terrain using three support points, which will also set the orientation of the object.

              Altitude in the animation is ignored, and the object is ground clamped to the terrain using only its origin point. Orientation is set solely from the animation.

              Altitude in the animation is used as the altitude above the terrain height.

              Acts like High Fidelity for frames where altitude is 0, and acts like None (Geodetic) for frames where altitude is non-zero.

              Radar Face Cartesian Similar to None (Topographic), except the Y coordinate is

              inverted. The animation would typically be started with an orientation reference corresponding to the angle of a radar face. Useful for cases where animation data is captured radar data.

              image


          5. Click OK.


        2. Configuring Animated Movement

          The animated movement feature lets you script a sequence of entity movements. You can do this using a CSV file or a 3DS ASCII Export (ASE) file. VR-Forces includes some sample animated movement files.

          Animated movement is assigned to an entity as a task from the Movement submenu. You configure the animated movement options in the Simulation Object Editor.

          To configure animated movement:

          1. Choose Edit Animated Movement. The Animated Movement dialog box opens (Figure 65-30).


            image

            Figure 65-30. Animated Movement dialog box

          2. To edit an existing animated movement, select it in the Animated Movement list. To create a new animated movement:

            1. Click the Add button next to the Animated Movement list. The New Configu- ration dialog box opens.

            2. Type a name for the new animated movement.

            3. Click OK.

          3. Optionally, type a description for the animated movement. This description is displayed in the Animated Movement dialog box when an Animated Movement task is assigned.

          4. In the Categories window, select the categories that this animated movement applies to. Use the Add and Delete buttons to add and delete categories.


          5. In the Movement File list, select the movement file to use. The list lists the files in

            ./data/simulationModelSets/<model_set>/scriptedObjectMovement. If you want to use a CSV file or ASE file that is not listed:

            1. Click the Add button next to the Movement File list. A file chooser dialog box opens.

            2. Select the file that you want to use. The file is copied to ./data/simulationModel- Sets/<model_set>/scriptedObjectMovement.

          6. If you chose an ASE file, the dialog box displays a field called Animation. Select an animation from the list.

            If you chose a CSV file, it displays a field called File Configuration. Select a file configuration from the list. File configurations specify the type of value in each column in the movement file. For details, please see “Editing Movement File Configurations,” on page 65-51.

          7. In the Clamp Type list, select an option for calculating the altitude. For details, please see Table 65-1.

          8. In the Completion Rule list, select the action you want the entity to take after it completes the animated movement task.


        3. Editing Movement File Configurations

          VR-Forces assumes that a ballistic missile CSV file contains four columns of data that describe time, lateral distance, altitude, and range. It assumes that animated movement files have seven columns that describe time, lateral distance, altitude, range, heading, pitch, and roll. VR-Forces includes file configurations for the sample CSV files provided. They are organized in the order that the columns are listed in this paragraph. If a CSV file you are using is organized differently, you must create a file configuration that matches your file or edit one of the provided configurations.


          To create or edit a movement file configuration:

          1. In the Ballistic Missiles dialog box or the Animated Movement dialog box, click the Edit button image) next to the File Configuration list. The Edit Movement Data File Configurations dialog box opens (Figure 65-31).


            image

            Figure 65-31. Edit Movement Data File Configurations dialog box


            image

            i

            i

            • Ballistic missile file configurations have four rows. Animated movement file configurations have seven rows. If you specify a seven-row configura- tion for a ballistic missile, it ignores the values that it does not use.

            • If you are editing an animated movement that uses an ASE file, there is no File Configuration option. This only applies to CSV files.


            image


          2. In the Movement File Configurations list, select the configuration you want to edit. If you are creating a new configuration, click the Add button. The New Configuration dialog box opens.

            1. Type a name for the configuration.

            2. Click OK.

          3. Optionally, change the Start Row value. This is the row in the CSV file from which VR-Forces should start reading values for entity movement.

          4. Specify the column in the CSV file that has the Time value.

          5. Optionally, select the time unit from the list.

          6. Repeat steps 4 and 5 for each movement parameter.

          7. Click OK.


      1. Editing Tactical Graphics

        You can add tactical graphics and edit existing tactical graphics just like you can add and edit simulation objects. You can create a new tactical graphic from an existing one or create a new tactical graphic using one of the basic graphic types - point, route, area, symbol, box, or circle.

        When you edit a tactical graphic, you can change the default characteristics of that tactical graphic. When VR-Forces users create one of these graphics, they can edit its specific characteristics as desired.

        The basic procedures for adding and editing tactical graphics are the same as for adding and editing simulation objects. This section describes procedures that are specific to tactical graphics.


        1. Editing a Tactical Graphic’s Menu Icon

          Most objects on the Create menu and the various object creation palettes have icons associated with them. For simulation objects, the icon is the icon used to represent them in the front-end. For tactical graphics, the icon illustrates the type of graphic. You can change the icon associated with a tactical graphic and add icons for newly created tactical graphics.

          image

          To specify the palette icon for a tactical graphic, click the Browse button ( ) for the Menu Icon line (Figure 65-5) and select the icon that you want to use.

          image

          To remove the icon associated with a tactical graphic, click the Delete button ( ) on the Menu Icon line.


        2. Setting the Default Values for Tactical Graphics Properties

          When you select a tactical graphic, the Visual Model group box displays all of the prop- erties that can be set for all of the different types of tactical graphics. Properties that do not apply to the selected tactical graphic are disabled. You can set default values for all of the properties that are applicable to the selected graphic. Setting a default value does not mean that the property will be editable in the VR-Forces front-end. The properties that are editable in the front-end are determined by keywords. For details, please see “Specifying the Properties that can be Edited in the Front-End,” on page 65-55.

          To set a default value for a tactical graphic property:

          1. In the Categories list, select one of the tactical graphics categories.

          2. In the list of tactical graphics, select the one that you want to edit. The applicable properties are enabled in the Visual Model group box (Figure 65-32).


            image

            Figure 65-32. Tactical graphics properties

          3. Set the default values.


        3. Specifying the Properties that can be Edited in the Front-End

          When you create a tactical graphic in the front-end, you can edit its properties, such as line style, line width, color, and fill. The properties that you can edit in the front-end are determined by keywords that you specify in the Simulation Object Editor.

          The keywords are as follows:

          • min=<num>. Specifies the minimum number of points required to create the object.

          • max=<num>. Specifies the maximum number of points allowed.

          • nostyle. Do not allow style editing.

          • freehand. The object can be drawn freehand.

          • penstyle. The user can change line style for the object.

          • fill. The user can change the object’s fill.

          • arrow. The user can change the object’s arrow style.

          • arrowsize. The user can change the object’s arrow size.

          When you edit a tactical graphic in the front-end, VR-Forces builds an Edit Style dialog box with the properties specified by the keywords. If no editing is allowed, it removes the Edit icon from the Edit object dialog box.

          To allow a tactical graphic’s properties to be edited, type the appropriate keyword in the Keywords text box. Separate each keyword with a semi-colon (;).


        4. Editing the Visual Model for a Tactical Graphic

          The visual model for a tactical graphic is based on a schema or on a texture. Schemas employ vector graphics and are best for basic lines, points, and areas. Textures apply raster images and are used primarily for specialized linear and areal graphics, such as fortified lines and minefields. (If you use a texture for a graphic, you cannot edit its style properties.)

          To edit the visual model for a tactical graphic:

          1. In the Categories list, select the category for the tactical graphic that you want to edit.

          2. In the list of tactical graphics, select the one that you want to edit.

          3. In the Visual Model group box, in the Model Sets list, select the model set that you want to edit.

          4. Click the Edit button. The Select Schema for Model Set model_set dialog box opens (Figure 65-33).


            image

            Figure 65-33. Select Schema for Model Set dialog box

          5. Select the schema that you want to use.

          6. Click OK.


            Editing the Texture for a Tactical Graphic

            When you use a texture for a tactical graphic you specify a model definition and the height and width of the texture.


            To specify a texture for a tactical graphic:

            1. In the Categories list, select one of the tactical graphics categories.

            2. In the list of tactical graphics, select the one that you want to edit.

            3. In the Visual Model group box, in the Model Sets list, select the model set that you want to edit.

            4. Click the Texture button. The Select Texture dialog box opens (Figure 65-34).


              image

              Figure 65-34. Select Texture dialog box

            5. Click the Browse button image). The Select Model Definition dialog box opens (Figure 65-35).



              image

              Figure 65-35. Select Model Definition dialog box

            6. Select the model definition that you want to use for this texture.

            7. Click OK.

            8. In the Select Texture dialog box, specify the width and height of the texture, in pixels.

            9. If this is an areal graphic, specify whether or not to use the texture for the outline of the area. If you do not use the texture, a regular line is used.

            10. Click OK.


    image

    66. Editing Units for Entity- Level Scenarios


    This chapter explains how to edit units for entity-level scenarios (EntityLevel.sms) in the Simulation Object Editor.

    Introduction to Editing Units 66-2

    Creating a Unit for Entity-Level Scenarios 66-2

    Specifying an Aggregate As Option 66-3

    Editing Unit Composition 66-4

    Adding Subordinates 66-5

    Removing Subordinates 66-5

    Replacing Subordinates 66-6

    Changing the Order of Subordinates 66-6

    Editing a Subordinate Unit 66-7

    Editing Formations 66-8

    Adding Formations 66-9

    Removing Formations 66-10

    Renaming Formations 66-10

    Specifying the Default Formation 66-10

    Expanding and Collapsing the Display of Formations 66-10

    Displaying Bounding Boxes 66-11

    Copying Formations 66-12

    Laying Out a Formation Automatically 66-13

    Changing a Formation’s Layout by Hand 66-13

    Editing Units for Entity-Level Scenarios — Introduction to Editing Units

    image

      1. Introduction to Editing Units

        VR-Forces can simulate units in two different ways:

      2. Creating a Unit for Entity-Level Scenarios

        To create a unit for entity-level scenarios:

        1. Follow the procedures for creating a new entity in “Creating a New Simulation Object,” on page 65-32.

        2. Add subordinates, as described in “Adding Subordinates,” on page 66-5.

        3. Optionally, configure formations.

        Editing Units for Entity-Level Scenarios — Specifying an Aggregate As Option

        image

      3. Specifying an Aggregate As Option

        When you create a unit using the Aggregate As command, the Aggregate As dialog box has a list of unit types that you can select for the unit that is to be created. VR-Forces is configured with just a short list of generic unit types. You can specify that any unit configured in the Simulation Object Editor be included in the list of Aggregate As options.


        image

        i This procedure is valid for entity-level and aggregate-level SMSs.

        image

        To specify that a unit can be an option in the Aggregate As list:

        1. Select the unit in the object list.

        2. Select the Allow as Aggregate As Option check box.


      4. Editing Unit Composition

    Each unit provided with VR-Forces has a predefined set of subordinates.


    image

    i

    i

    The Convoy unit provided with VR-Forces is an exception to the discussion of units in this section. It does not have an Auto Aggregation Controller, which allows a unit to aggregate and disaggregate. Although you can assign this controller, it is not recommended, because the resulting behavior would be undefined.


    image


    Figure 66-1 illustrates the Simulation Object Editor with a unit selected. The Unit Composition group box is highlighted.


    image

    Figure 66-1. Unit Composition


        1. Adding Subordinates

          When you create a new unit without copying an existing unit, you must specify its subordinates. You can also edit subordinates for existing units.

          To add a subordinate to a unit:

          1. In the Unit Composition group box (Figure 66-1), click Add. The Add to Hier- archy dialog box opens (Figure 66-2).


            image

            Figure 66-2. Add to Hierarchy dialog box

          2. In the list of simulation objects, select the simulation object that you want to add.

          3. Click Add. The simulation object is added to the list in the Unit Composition window. It is also added to each formation using a default layout algorithm.

          4. Continue to add as many subordinates as desired.

          5. Click Close.


        2. Removing Subordinates

          To remove a subordinate from a unit:

          1. In the Unit Composition window (Figure 66-1), select the subordinate that you want to remove.

          2. In the Unit Composition group box, click Remove. The subordinate is removed from the unit.


        3. Replacing Subordinates

          Replacing a subordinate is a convenient way to remove a subordinate and insert a different subordinate in the same location in one step.

          To replace a subordinate:

          1. In the Unit Composition window (Figure 66-1), select the subordinate that you want to replace.

          2. In the Unit Composition group box, click Replace. The Add to Hierarchy dialog box opens (similar to Figure 66-2).

          3. In the list of simulation objects, select the object that you want to add as a replace- ment.

          4. Click OK. The new object replaces the selected simulation object in the Unit Composition window. It is also added to each formation in the location of the replaced simulation object.


        4. Changing the Order of Subordinates

          The order of subordinates in the Unit Composition window determines which entity is the leader, the order in which units are placed into formation, and the succession when units are reorganized.

          To change a subordinate’s position in the unit composition:

          1. In the Unit Composition window (Figure 66-1), select the subordinate that you want to move.

          2. In the Unit Composition group box, click Move Up or Move Down.


        5. Editing a Subordinate Unit

          Units can contain entities and other units as subordinates. When you are editing a unit, you might decide that you want to edit one of its subordinates. You can jump to the subordinate quickly without selecting it in the main list of simulation objects.


          image

          !

          !

          If you edit a subordinate unit, the changes affect all uses of that subordinate, not just the one in this particular unit.


          image


          To edit a subordinate:

          1. In the Unit Composition window or in the Formation Editor, right-click the subordinate that you want to edit. A menu is displayed.

          2. In the menu, choose Edit. The Simulation Object Editor redisplays to show the selected subordinate. (If the Formation Editor is open, you must close it before you can edit the subordinate.)


    Navigating the Subordinate Hierarchy

    If you jump to a subordinate in the Simulation Object Editor, you can quickly back up to its superior unit by clicking the back arrow above the object list (Figure 66-3).


    image

    Figure 66-3. Forward and Back arrows


    image

      1. Editing Formations

        Each unit in EntityLevel.sms has the following defined formations:

        • Column

        • Line

        • Vee

        • Wedge.


          image

          i

          i

          The Convoy unit provided with VR-Forces is an exception to the discussion of units in this section. It does not have any formations because there is no preconceived membership in a convoy.


          image


          You can add, remove, and rename formations. You can also:

        • Change the layout of subordinates in a formation.

        • Create new formations.

        • Specify the default formation.

          The Formation Editor allows you to change the display of formations as follows:

        • Expand and collapse the display of subordinate units.

        • Zoom in and out on the display.

        • Display subordinate bounding boxes.

    You can also edit formations in formation files. For details, please see “Configuring Formations,” on page 73-2.


        1. Adding Formations

          To add a formation:

          1. In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).


            image

            Figure 66-4. Formation Editor

          2. In the Formation Editor, click Add. The Add Formation dialog box opens (Figure 66-5).


            image

            Figure 66-5. Add Formation dialog box

          3. In the Formation Name box, type a name for the formation.

          4. In the Copy Formation list, select an existing formation to copy the new formation from.

          5. Click OK.

          6. Edit the layout of the formation as described in “Changing a Formation’s Layout by Hand,” on page 66-13.


        2. Removing Formations

          To remove a formation:

          1. In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).

          2. In the Formation Editor, select the tab for the formation that you want to remove.

          3. Click Remove. The tab is removed.


        3. Renaming Formations

          To rename a formation:

          1. In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).

          2. In the Formation Editor, select the tab for the formation that you want to rename.

          3. Click Rename. The New Name dialog box opens.

          4. Type a name for the formation.

          5. Click OK.


        4. Specifying the Default Formation

          The default formation is the formation assigned to a unit when you create it in VR- Forces. The default formation is the leftmost tab in the Formation Editor.

          To specify the default formation:

          1. In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).

          2. In the Formation Editor, select the tab of the formation that you want to specify as the default formation.

          3. Click Default. The selected tab gets moved to the leftmost position.


        5. Expanding and Collapsing the Display of Formations

          You can expand and collapse the display of formations in the Formation Editor window. This lets you see how simulation objects are dispersed over the terrain. It can help you quickly identify any unintended variations in subordinate formations.

          To expand or collapse the display of formations in the Formation Editor, click the Expand or Collapse buttons.


        6. Displaying Bounding Boxes

          You can display bounding boxes for the subordinate units in a unit. This may be useful when you collapse the views of individual units, but you still want to have a sense for the area that they occupy. Figure 66-6 illustrates a unit with the display of bounding boxes off and on.



          image


          Figure 66-6. Unit bounding boxes in Formation Editor

          To display or hide bounding boxes, in the Formation Editor (Figure 66-4), select or clear the Bounding Boxes check box.


        7. Copying Formations

          You can copy formations from one unit to another. When you copy formations, the subordinates in the unit are laid out in each formation according to their order in the Unit Composition window.

          To copy a formation:

          1. In the object list, select the unit that you want to copy formations to.

          2. In the Unit Composition group box, click Edit Formation. The Formation Editor opens (Figure 66-4).

          3. In the Formation Editor, click Copy. The Select Formations dialog box opens (Figure 66-7).


            image

            Figure 66-7. Select Formations dialog box

          4. In the Aggregates list, select the unit whose formations you want to copy.

          5. In the window, select the formations that you want to copy.

          6. Click OK. The formations are copied from the selected unit to the currently displayed unit.


        8. Laying Out a Formation Automatically

          You can automatically distribute the simulation objects in a unit into one of the built-in formations. You can specify the distance between each entity in the formation.

          To lay out a formation automatically:

          1. In the Unit Composition group box, click Edit Formation. The Formation Editor opens (Figure 66-4).

          2. In the Formation Editor, select the tab for the formation that you want to lay out.

          3. Click Auto Layout. The Auto Layout dialog box opens.

          4. In the list, select a formation type.

          5. Specify the distance, in meters, between each entity in the formation.

          6. Click OK. The simulation objects in the unit are reorganized to the new layout.


        9. Changing a Formation’s Layout by Hand

          You can lay out a formation by hand. The gridline in the Formation Editor indicates the center of the formation (Figure 66-8). This is where the unit icon is placed when the unit is collapsed or aggregated.


          image

          Figure 66-8. Formation Editor crosshair

          To change a formation’s layout:

          1. In the Unit Composition group box, click Edit Formation. The Formation Editor opens (Figure 66-4).

          2. In the Formation Editor, select the tab for the formation that you want to lay out.

          3. Drag each subordinate to the location where you want it to be.


    Snapping Subordinates to the Grid

    When you lay out a formation you can specify that simulation objects snap to the grid. That is, they can only be placed at the intersection of vertical and horizontal grid lines. When snap-to-grid is enabled, if you want to place simulation objects more closely together than the grid allows, you can change the scale factor.

    To enable snap-to-grid for entity placement, in the Formation Editor, select Snap To Grid.


    Changing the Grid Spacing

    Grid spacing determines the distance, in meters, between grid lines. The default is 1000 meters.

    To change the grid spacing, enter a value in the Grid Spacing box.


    image

    67. Editing Aggregate-Level Objects


    This chapter explains how to edit simulation objects and combat engineering objects for aggregate-level modeling.

    Creating Objects for Aggregate-Level Modeling 67-3

    Configuring Simulation Objects for Aggregate-Level Modeling 67-3

    Aggregating Units into Higher Echelon Units 67-4

    Configuring Ammunition, Weapons, and Equipment 67-5

    Defining Ammunition, Weapons, and Equipment Items 67-8

    Assemblies 67-10

    Creating Assemblies 67-11

    Editing Assemblies 67-12

    Adding Assemblies to a Unit 67-13

    Removing Assemblies 67-13

    Creating Roll Up Rules 67-14

    Rolling Up Assemblies 67-15

    Adding Activities 67-16

    Setting Object Parameters for Aggregate-Level Modeling 67-17

    Physical Parameters 67-18

    Movement Parameters 67-19

    Sensor Parameters 67-21

    Attack Parameters 67-22

    Defense Parameters 67-23

    Electronic Warfare (EW) Parameters 67-23

    Personnel and Equipment Parameters 67-24

    Supplies Parameters 67-24

    Configuring Combat Engineering Objects 67-25

    image

    Editing Aggregate-Level Objects

    Editing Reader/Writer Key/Value Pairs 67-26

    Editing Aggregate-Level Objects — Configuring Simulation Objects for Aggregate-Level Model-

    ing

      1. Creating Objects for Aggregate-Level Modeling

        You create new aggregate-level simulation objects and combat engineering objects the same way you create entity-level objects, by creating a new model or creating an object from an existing model.

        Simulation objects in an aggregate-level scenario have a more complex set of parameters than simulation objects in an entity-level scenario, so ensuring consistency among similar types of simulation objects could become difficult if after creating new models you had to configure all of the parameters from scratch or if after creating a model from an existing model you had to back out all of the assemblies and parameters that you wanted to change. Therefore, VR-Forces includes templates for common entity types. If you create a new model from a template (by selecting a template and then choosing Model New Model From Existing), you know that you will have a simulation object with similar characteristics to other simulation objects of its type, that is ready to customize with assemblies or direct specification of equipment, weapons, and personnel.


      2. Configuring Simulation Objects for Aggregate-Level Modeling

        Simulation objects for aggregate-level modeling (those used in the aggregate warfare model) are configured in the Simulation Object Editor (AggregateLevel.sms). Some aspects of their configuration, such as name, enumeration, and categories are the same as for simulation objects in an entity-level scenario. Other parameters, the focus of this chapter, are used in the aggregate warfare model (Figure 67-1).


        image

        Figure 67-1. Unit in AggregateLevel.sms

        Editing Aggregate-Level Objects — Configuring Simulation Objects for Aggregate-Level Model- ing

        The parameters for simulation objects in AggregateLevel.sms are organized into the following groups:

        • Physical. Overall health of the simulation object, its footprint, and sector size for each posture.

        • Movement. The movement system to use and how speed is modified by different postures and MOPP levels.

        • Sensors. Sensor systems and signatures (similar to simulation objects in an entity- level scenario) and how signatures are modified by different postures and MOPP levels.

        • Attack. Specifies combat power, ammunition use, weapon systems, and modifiers to combat power.

        • Defense. Specifies vulnerability to different types of attack and modifiers to vulner- ability.

        • EW. Specifies electronic warfare systems, EW defense, and dependence.

        • Personnel and Equipment. Lists personnel and equipment. This information is not used by the back-end in simulations. It is reported as part of the simulation object’s state information.

        • Supplies. Specifies the supplies a simulation object needs to move, support personnel, and carry out combat engineering operations.

        • Engineering. Lets you specify engineering systems.

        • Additional Systems. Similar to simulation objects in an entity-level scenario, this tab lets you add other systems such as spot report systems.

    The individual parameters in each group are described in “Setting Object Parameters for Aggregate-Level Modeling,” on page 67-17.

    To configure a simulation object, you specify values for as many of the parameters as are appropriate for the object type. However you cannot configure ammunition, weapons, and equipment (aircraft, ships, and vehicles), without first defining them.


    67.2.1. Aggregating Units into Higher Echelon Units

    You can aggregate simulation objects into higher echelon units. And just as with simu- lation objects in entity-level scenarios, you specify that a simulation object can be listed in the Aggregate As list by selecting the Allow as Aggregate As Option check box.

    However, the aggregate-level simulation objects that are configured to use the aggregate warfare model do not have the configuration options for specifying subordinates.

    Therefore, AggregateLevel.sms has a platform, Aggregate Container, for use when aggre-

    gating simulation objects. The SMS has several simulation objects configured with that platform for use when aggregating simulation objects. If you want to create additional hierarchical units for aggregation, it is recommended that you use the Aggregate Container platform.


      1. Configuring Ammunition, Weapons, and Equipment

        To engage in combat, simulation objects need appropriate amounts of ammunition, weapons, and equipment. When you create a simulation object in the Simulation Object Editor, you specify the amounts that it should have by selecting them from lists of the available types of these resources. The items in these lists are also configured in the Simulation Object Editor. You can configure the ammunition, weapons, and equip- ment for simulation objects directly for each entity, or you can simplify the process by creating assemblies.

        For example, a U.S. armored cavalry troop (AR CAV TRP US) has 9 M1A2s, 13 M3A3s, and 2 M1064 vehicles. An M1A2 has a 120mm gun, a 12.7mm machine gun, and 2 7.62 mm machine guns. An M3A3 has 2 TOW missiles, a 25mm gun, and a 7.62mm machine gun. An M1064 has a 120mm mortar and 12.7mm machine gun. Therefore, the entity as a whole has 26 TOW missiles, 13 25mm guns, 9 120mm guns, 11 12.7mm machine guns, 31 7.62mm machine guns, and 2 120mm mortars (Figure 67-2).


        image

        AR CAV TRP US Unit



        ATGM TOW (26)

        image

        Gun 25mm (13) Weapons


        Gun 120mm (9)

        Gun 120mm (9)


        MG 12.7mm (11)

        MG 12.7mm (11)


        MG 7.62mm (31)

        MG 7.62mm (31)


        Mortar 120mm (2)

        Mortar 120mm (2)


        Figure 67-2. Anatomy of a unit without using assemblies

        To configure this unit directly, you would go to the Personnel and Equipment tab in the Simulation Object Editor and select all these weapons in the Weapons list and enter the amounts for each. You would also have to add up all the ammunition required by these weapons and enter them on the Attack tab.

        This configuration method works fine for simple units and individual entities. However, if you had to calculate weapons and ammunition at this level of granularity for all units, it could become a tedious and error-prone activity. However, there is an alternative to directly configuring all ammunition, weapons, and equipment individu- ally. You can create assemblies. Assemblies are resources such as complete weapons, vehicles, or even small units, such as platoons. They are a convenient way to package ammunition, weapons, and equipment to more easily add them to units.


        Each assembly configures the ammunition and weapons it needs for one instance of the resource, such as an M1A2. When you create a unit, you just give it the assemblies it needs. Their capabilities are “rolled up” to define the total amount of resources for the entity.

        Figure 67-3 illustrates the anatomy of an AR CAV TRP US entity that uses assemblies to represent M1A2, M3A3, and M1064 vehicles. Each assembly specifies its weapons and ammunition. When you configure the AR CAV TRP US, you just specify that it has 9 M1A2, 13 M3A3, and 2 M1064 assemblies. You roll up the assemblies and the Simulation Object Editor calculates the number of each type of weapon needed (Figure 67-4).



        M1064


        M1064

        image

        image

        image

        AR CAV TRP US Aggregate




        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2

        M1A2 (9)



        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2

        M1A2 (13)


        M1064 (2)

        Assemblies



        M1A2


        M1A2


        M1A2


        M1A2


        M1A2


        M1A2

        Gun 120mm

        Gun 120mm

        ATGM TOW (2)

        ATGM TOW (2)

        Mortar 120mm

        Mortar 120mm

        Weapons

        MG 12.7mm

        MG 12.7mm

        Gun 25mm

        Gun 25mm

        MG 12.7mm

        MG 12.7mm

        (per assembly)


        MG 7.62mm (2)

        MG 7.62mm

        MG 7.62mm (2)

        MG 7.62mm


        Figure 67-3. Anatomy of a unit using assemblies


        image

        Figure 67-4. AR CAV TRP US weapons rolled up on Personnel and Equipment tab

        Using assemblies, the process for configuring units is to:

        1. Define the weapons, equipment, and ammunition that units can use.

        2. Define assemblies.

        3. Create a unit.

        4. Specify the unit’s assemblies.

        5. Roll up the assemblies.

        6. Configure all other parameters.

    For more information about assemblies, please see “Assemblies,” on page 67-10.


        1. Defining Ammunition, Weapons, and Equipment Items

          Each ammunition, weapon, and equipment item that you want to be available for use by simulation objects is defined as a key/value pair. The key can be any text string you want to use. There is no relationship to any underlying VR-Forces code. The value is a Display Name – the string used in lists when creating assemblies or adding resources directly to a simulation object.

          For each ammunition key/value pair you also must specify a type, where the types are:

          • Anti-air

          • Anti-personnel

          • Anti-ship

          • Anti-tank

          • Biological

          • Chemical

          • High explosive

          • Nuclear

          • For weapon system.

    Use the anti-air, anti-personnel, anti-tank, and anti-ship categories for ammunition that will be used by assemblies or added directly to a simulation object. Use For Weapon System for any type of ammunition that will be used by a weapon system that must be added to a simulation object, such as a missile system, a guided bomb, or indirect fire system.

    For each weapon and equipment key/value pair, you also must specify a category, where the categories are aircraft, ships, vehicles, and weapons.

    The ammunition, weapons, and equipment defined in AggregateLevel.sms are represen- tative of the weapons and equipment in common use by the United States and Russia. However, you can add any sort of resource you want. For example, you could create entries for knives, sling shots, and shovels. These could be added to assemblies or directly to a simulation object. The only real requirement for making them useful in a scenario is to assign an appropriate level of combat strength when you add them to a simulation object.


    To define an ammunition, equipment, or weapon item:

    1. Choose Edit Ammunition and Equipment. The Edit Ammunition and Equipment dialog box opens (Figure 67-5).


      image

      Figure 67-5. Edit Ammunition and Equipment dialog box

    2. Select the tab for the type of resource you want to add.

      image

    3. Click the Add button ( ). A row is added to the list. The Key cell is editable.

    4. Type the key value.

    5. Click Tab or double-click the Display Name cell to make it editable.

    6. Type the text you want to be visible in the lists where this item will be included.

    7. For ammunition items, select an option in the Type list. For equipment items, select the appropriate category. For weapon items, select Weapon Category.

    8. Click OK.


      1. Assemblies

        Assemblies are a convenient way to provide a simulation object with a set of resources without having to individually configure each resource.

        A unit does not model individual entities. It represents some number of vehicles and personnel. For example, a mechanized infantry company has personnel, armored personnel carriers, and so on, which carry a variety of weapons and ammunition.

        Rather than explicitly configuring a unit to have, for example, 20 APCs, 20,000 rounds of ammunition, 10 howitzers, and 200 infantry, you can configure the ammunition and weapons for one APC as an assembly. Then you would assign a unit 20 APC assem- blies. You would not have to tally all the resources associated with an APC.

        This becomes even more beneficial if more than one unit uses an assembly. For example, the Scout Hvy PLT US unit uses M3A3 assemblies. The Tank CO US uses M1A2 assemblies. The AR CAV TRP US uses M1A2s, M3A3s, and M1064 assem- blies. While it might be a manageable process to configure M1A2s just for one unit and M3A3s just for one unit, to use them in multiple units and have to calculate the sum of all of their weapons and ammunition each time would become tedious and error-prone. Using assemblies makes it easy to assign multiple units of each type to a unit.


        1. Creating Assemblies

          When you create an assembly, you specify the equipment, weapons, ammunition, vari- ables, and systems that get configured for a simulation object when you add the assembly to it.

          To create an assembly:

          1. Choose Edit Assemblies. The Edit Assemblies dialog box opens (Figure 67-6).


            image

            Figure 67-6. Edit Assemblies dialog box

            image

          2. Click the Add button ( ). The New Assembly dialog box opens.

          3. Type a name for the assembly.

          4. Optionally, select an assembly to base the new one on.

          5. Click OK. The new assembly is added to the Assembly list.

          6. Edit the assembly.


        2. Editing Assemblies

          An assembly specifies equipment, weapons, ammunition, variables, and systems. Vari- ables represent entity resources that do not fit into weapons, ammunition and equip- ment. These include tangible resources, such as fuel, water, and personnel, and intangible variables, such as health and combat power. If you do not specify particular variables for an assembly, you can specify them directly for a simulation object.

          When you create an assembly, you can edit the properties of its systems. You can also edit system properties when you edit a simulation object. Many system properties do not change when you roll up a unit, but some do. For example, indirect fire weapons have a maximum sheaf parameter. The default maximum sheaf value for the 155mm howitzer is 80 meters. If an artillery unit has six howitzers and you roll it up, the maximum sheaf value for the howitzers in that entity becomes 480.


          image

          !

          !

          If you specify variables for an assembly, when you roll up assemblies, the variables in the assembly overwrite the values that have been set directly. Therefore, it is recommended that you use them consistently in all your assemblies and that you not edit these values directly in a unit if you know that you will use assemblies that might overwrite them.


          image


          To edit an assembly:

          1. Choose Edit Assemblies. The Edit Assemblies dialog box opens (Figure 67-6).

          2. In the Assembly list, select the assembly that you want to edit.

          3. For the Equipment, Weapons, Ammunition, and Variables tabs, do the following:

            image

            1. Click the Add Attribute button ( ). A new row is added to the list of resources on the tab. In the Element column, it lists the first resource in the list of avail- able resources.

            2. In the Element list, select the resource you want to add to this assembly.

            3. Double-click the Value cell to make it editable.

            4. Type the amount of this resource that you want to be in this assembly.

          4. For the Systems tab, add a system as described in step 3. There is no Value column to complete, but you can edit the system’s properties. To edit properties:

            1. Click the Edit Properties button image). A Properties dialog box opens.

            2. Set the property values as desired.

          5. Click OK.


        3. Adding Assemblies to a Unit

          You can configure individual vehicles and weapons for a unit, or you can add assem- blies, which add all the relevant parameters and combine them for the number of instances of each assembly that you add.

          To add an assembly to a unit:

          1. Select the entity in the object list.

            image

          2. Click the Add button ( ) above the Assemblies list (Figure 67-7). A new row is added to the list.


            image

            Figure 67-7. Assemblies table

          3. In the Assembly column, select an assembly from the list.

          4. Double-click the Amount value to make it editable.

          5. Enter how many of this assembly that you want to add.


        4. Removing Assemblies

          To remove an assembly:

          1. In the Assemblies list, select the index number or any cell in the assembly you want to remove.

            image

          2. Click the Delete button ( ).

            Editing Aggregate-Level Objects — Creating Roll Up Rules

            image

      2. Creating Roll Up Rules

        VR-Forces rolls up assemblies based on a set of rules. Roll up rules are not specific to simulation objects; they are global for an SMS. A roll up rule specifies the assemblies to roll up and the formula to use to roll them up, as follows:

        • Sum. Add up the values for all the assemblies.

        • Average. Use the average value for identical variables in the assemblies.

        • Maximum. Use the highest value specified for identical variables in the assemblies.

        • Minimum. Use the lowest value specified for identical variables in the assemblies.


        image

        i

        i

        Ammunition, weapons, equipment, and systems are all rolled up by summation. There are no user-editable roll up rules for these resources.


        image


        To create roll up rules:

        1. Choose Edit Roll Up Rules. The Edit Roll Up Rules dialog box opens (Figure 67-8).


          image


          Figure 67-8. Edit Roll Up Rules dialog box

          image

        2. Click the Add button ( ). A new row is added to the list.

        3. Select the type of roll up item from the list.

        4. Specify a Display Name.

        5. Specify a default value.

        6. Select an option in the Roll Up Rule list.

          Editing Aggregate-Level Objects — Rolling Up Assemblies

          image


        7. If you are adding an Average roll up type rule, select an option in the Weight list. This creates a weighted average based on the item you want to give greater weight, such as health or vulnerability.

        8. Add additional items as desired.

        9. Click OK.


      3. Rolling Up Assemblies

        Once you assign a set of assemblies to a unit, you roll them up so that the full set of resources is applied to the unit. Assemblies are rolled up according to roll up rules.


        image

        !

        !

        When you roll up assemblies, the resources and modifiers in the assemblies overwrite the current values for the unit. If you have edited any of these resources or modifiers manually, your changes are lost. Any parameters that are not part of an assembly or roll up rules do not change.


        image


        To roll up assemblies for a unit:

        1. Select the unit.

        2. Choose Edit Roll Up All, or in the Assemblies area of the Simulation Object Editor window, click Roll Up. You are prompted to confirm the command.

        3. Click Yes.

        Editing Aggregate-Level Objects — Adding Activities

        image

      4. Adding Activities

        You can assign simulation objects an activity. The Simulation Object Editor lets you add activities. When you add an activity, it is included in the list of activities for the Activity set data request. However, unless you add code or a Lua script that takes advan- tage of the new activity setting, assigning an activity to a simulation object will have no effect.

        To add an activity to the Activities list:

        1. Choose Edit Activities. The Edit Activities dialog box opens (Figure 67-9).


          image

          Figure 67-9. Edit Activities dialog box

          image

        2. Select an object type in the Entity Type list, or click the Add button ( ) to add a new type.

          image

        3. Click the Add Attribute button ( ). A new entry is added to the list of activities. The Key cell is active for editing.

        4. Type a key value for the activity. This is the value that the code or Lua script uses to identify the activity.

        5. Press Tab or double-click in the Display Name cell to make it editable.

        6. Type the text to display in the Activities dialog box.

        7. Click OK.


      5. Setting Object Parameters for Aggregate-Level Modeling

    The aggregate warfare model is data driven. It relies on the comparative strengths of opponents given their resources and movement posture. The data used is from an extensive set of parameters that are configured for each simulation object in the Simula- tion Object Editor.

    Most parameters are in one of the following categories:

    For the simulation objects in AggregateLevel.sms provided with VR-Forces, real-world values are based on publicly available information about the types of simulation objects. The various modifiers applied to simulation object behavior are derived from customer requirements for the aggregate warfare model. Modifier values have been set from experimentation to provide what we believe to be realistic results. Values for health and strength have also been developed on a relative scale to obtain reasonable results.

    If you add new simulation objects to AggregateLevel.sms, it is important that you try to set health and strength to values that fit with the existing simulation objects. If you create an entirely new SMS for aggregate-level scenarios, you are responsible for devel- oping your own consistent way to represent the relative strengths of the simulation objects.

    Parameters are organized in a set of tabbed pages. The following sections describe the parameters on each tab. The Additional Systems tab does not include aggregate warfare parameters. It lets you specify systems that did not logically belong on the other tabs.


        1. Physical Parameters

          Physical parameters describe a simulation object’s footprint and how it faces the external world for each posture, which is a simulation object’s overall mode of interac- tion with its environment.

          image

          Parameter Description

          Parameter Description

          Table 67-1: Physical parameters


          Health A quantification of the overall health of the entity. Physical Footprint The area notionally occupied by the simulation object.

          The footprint can vary for different postures based on the Footprint Modifier.

          Footprint Modifier The amount by which the footprint changes for the indi-

          cated posture.

          Front Sector Size The number of degrees, centered on the heading, within

          which forward-facing sensors and interactions take place.

          Rear Sector Size The number of degrees, centered on the heading -180o,

          within which rear-facing sensors and interactions take place.

          Flank Sector Size The number of degrees, centered on the heading +/-

          90o, within which side-facing sensors and interactions take place.

          image


        2. Movement Parameters

          A unit has a movement system. You can specify the movement system on this tab and edit its parameters. You can also specify posture transition times.

          Movement can be affected by:

        3. Sensor Parameters

          The Sensors tab lets you specify the sensors that a simulation object has. You can add and remove sensor systems and set their properties using the standard Simulation Object Editor procedures. (For details, please see “Editing a Simulation Object’s Systems,” on page 65-28.)

          You can specify the simulation object’s sensor signatures by choosing from a preconfig- ured set of signatures or by defining a custom set. The Sensor Signatures parameters specify the distance at which other simulation objects can sense the simulation object you are editing using the different types of sensors. The preconfigured signatures make it easy to consistently apply the same set of signatures to similar object types.

          As with movement, a unit’s posture and MOPP level affect its ability to use its sensors. You can specify signature modifiers for each posture and MOPP Level.


        4. Attack Parameters

          Simulation objects have combat power in five domains: Anti-Air, Anti-Tank, High Explosive, Anti-Personnel, and Anti-Ship. The Attack tab specifies the parameters that determine a unit’s ability to attack an opponent in these domains. It also lets you add weapon systems to the simulation object.

          image

          Table 67-4: Attack parameters


          Parameter Description

          Parameter Description

          Range The distance at which a simulation object can attack in each domain.

          Hit Factor When compared to the defense factor for a target simulation object, determines the probability of the attack hitting the target.

          Strength The simulation object’s strength in each type of combat. This is an abstract value.

          Ammunition Usage The number of rounds per minute used for each type

          of combat. This value is apportioned among ammuni- tion of the same type. For example if the ammunition usage for Anti-Personnel combat is 1000 rounds per minute and a simulation object has 12.7mm ammuni- tion and 7.62mm ammunition, both of which are type Anti-Personnel, then the simulation object uses 500 rounds per minute of each type of ammunition.

          Ammunition Auto-Resupply Rate

          The amount of ammunition that is automatically resupplied each day if auto-resupply is enabled for this simulation object.

          Ammunition The types of ammunition this simulation object has, the amount of each type, and whether or not pacing or tracking is enabled.

          Distribution The proportion of casualty types from an attack.

          Sector Combat Power Modi- fiers

          Posture Combat Power Modi- fiers

          The amount the base combat power is modified depending on which sector is being attacked.

          The effect on combat power of each posture.

          Combat Range Modifiers The effect on the range at which a simulation object

          can attack based on its posture.

          CID Level Combat Power Modifiers

          MOPP Level Combat Power Modifiers

          The effect on combat power of the enemy detection and classification level.

          The effect on combat power of the MOPP Level.

          If Morale is Less Than A percentage of morale below which combat power is

          affected.

          Adjust Combat Power By The combat power modifier to apply if morale is less

          than the specified amount.

          image


          image

          Table 67-4: Attack parameters


          Parameter Description

          Parameter Description

          Environmental Conditions Combat Power Modifier


          Weapon System Auto- Resupply Rate

          The combat power modifier to apply if precipitation intensity is at its maximum or if there is no illumina- tion.

          The number of rounds per day supplied to each weapon system if auto-resupply is enabled.


          image


        5. Defense Parameters

          The Defense tab lets you specify modifiers to a simulation object’s vulnerability. Vulner- ability is specified within each weapon domain.

          image

          Table 67-5: Defense parameters


          Parameter Description

          Parameter Description

          Vulnerability The amount that a simulation object is vulnerable to the different types of attack.

          Defense Factor for Guided Munitions

          The ability to defend against guided munitions.

          NBC Vulnerability Vulnerability to nuclear, biological, or chemical contamination.

          Posture Vulnerability Modi- fier

          The effect of different postures on the simulation object’s ability to defend itself.

          Sector Vulnerability Modifier The ability of the simulation object to defend itself to

          the front, rear, and flanks.

          MOPP Level Vulnerability Modifier

          The ability of the simulation object to defend against NBC contamination at different MOPP Levels.


          image


        6. Electronic Warfare (EW) Parameters

          The EW tab lets you specify a simulation object’s ability to defend against electronic warfare and how much it depends on communications. You can add EW systems.


        7. Personnel and Equipment Parameters

          The Personnel and Equipment tab lets you specify the order of battle for the simulation object. These values are not used by the back-end in the simulation. They are for reporting purposes. The configured personnel and equipment amounts are multiplied by the simulation object’s health to arrive at the current amount.

          image

          Table 67-6: Personnel and Equipment parameters


          Parameter Description

          Parameter Description

          Personnel Officers Number of officers.

          Personnel WOs Number of warrant officers.

          Personnel NCOs Number of non-commissioned officers.

          Personnel Enlisted Number of enlisted persons.

          Equipment List of equipment types, the number of each, and whether it is flagged for pacing, tracking, or none.

          Weapons List of weapon types, the number of each, and whether it is flagged for pacing, tracking, or none.

          image


        8. Supplies Parameters

          The Supplies tab lets you specify the amount, use per day, use per kilometer, pacing/tracking, and auto-resupply rate for the following supplies:

    The supplies added here are only used by engineering objects. To use a supply, you configure it here and in the engineering object. For example, a combat engineering company has other supplies called Construction-Material and Explosives.

    This tab also lets you specify the conditions under which a simulation object can receive supplies.

    Editing Aggregate-Level Objects — Configuring Combat Engineering Objects

    image

      1. Configuring Combat Engineering Objects

        Combat engineering objects (CEOs) can affect mobility of simulation objects and can cause attrition. Therefore, their simulation models include the information needed for these effects. Since CEOs can be constructed by units, their models include parameters that specify the types of materials needed to create them and sizing information.

        The actual process of configuring CEOs is similar to that of other objects. Table 67-7 describes the parameters specific to CEOs. Some parameters do not apply to all CEOs.

        image

        Table 67-7: Combat engineering object parameters


        Parameter Description

        Parameter Description

        Short Name The name displayed on the map and sent as marking text over the network.

        Height The height of the object.

        Maximum length Maximum length of single constructed objects. If a

        longer object is specified, it is created as several objects.

        Width The width of a line object.

        Minimum Completion Percentage for Effect

        Minimum Completion Percentage to Detect

        The minimum completion percentage before the object affects simulation objects.

        The minimum completion percentage before simula- tion objects can detect the object.

        Attrition The rate of attrition to an affected simulation object in each domain.

        Mobility Modifiers The amount that mobility of an affected simulation

        object is modified in each type of movement.

        Vulnerability Modifiers The amount that an affected simulation object’s

        vulnerability is modified in each domain.

        Signature Modifiers For object types that can be affected by this object,

        the amount that each type of sensor signature is affected.

        Resource Required The type of resource needed to construct this

        object.

        Resource Amount The amount of the required resource needed to build

        this object.

        image

        Editing Aggregate-Level Objects — Editing Reader/Writer Key/Value Pairs

        image


        image

        Table 67-7: Combat engineering object parameters


        Parameter Description

        Parameter Description

        Is Concealed If selected, the object is detected based on a random probability in the detecting sensor. If cleared, the object is always detected by the appro- priate sensor.

        Maximum Relative Size For areal objects, the maximum size of a simulation

        object, relative to the object, for it to be affected by the object. For example, if the maximum relative size for a fortified area is .75, a simulation object must be 75% of the size of the area or smaller for it to be protected.

        image


      2. Editing Reader/Writer Key/Value Pairs

    Some display text is not automatically included in the untranslated.ts file provided with VR-Forces. The Simulation Object Editor lets you map some internal keywords to display text so that you can translate it. These internal keywords are called reader/writer keys and they are managed using key/value pairs. These mappings are stored in

    ./data/simulationModelSets/AggregateLevel/gui/rwKeywordValuePairs.xml. If you edit this

    file, do not change the paramName; change the string mapped to it.

    Besides allowing for translation, you can add new entries to this file. Table 67-8 describes the effect of adding new keyword:value pairs.

    image

    Table 67-8: Effect of editing rwKeywordValuePairs.xml parameters


    Parameter Result

    Parameter Result

    Type Added to the Type list for the Edit Ammunition and Equipment dialog box, Ammunition tab, in the Simulation Object Editor.

    Category Added to the Category list for the Edit Ammunition and Equip- ment dialog box, Weapon tab and Equipment tab, in the Simula- tion Object Editor.

    Posture Added to the list of Postures in the Posture set data request. However, selecting such a posture would not have any effect unless complementary code is written to update the simulation engine.

    Resource-Item Added to the Supply list for configuring Other Supplies on the Supplies tab for simulation objects in the Simulation Object Editor.

    image


    image 68. Adding DI-Guy Models to VR-Forces


    This chapter explains how to take DI-Guy models created with the DI-Guy SDK and integrate them into VR-Forces.

    Adding New DI-Guy Models to VR-Forces 68-2

    Copy DI-Guy Files to the Data Directory 68-2

    DI-Guy Configuration Files 68-3

    Adding a New DI-Guy Animation 68-4

    How VR-Forces Maps DI-Guy Models 68-5

    Add a New DI-Guy Entity in the Simulation Object Editor 68-5

    Adding DI-Guy Models to VR-Forces — Adding New DI-Guy Models to VR-Forces

    image

      1. Adding New DI-Guy Models to VR-Forces

        VR-Forces supports DI-Guy characters and includes many lifeform characters. However, MAK customers sometimes want to add their own DI-Guy characters. The general process for adding a new character is as follows:

        1. Create the new character using DI-Guy software and copy the required files to the

          ./data directory.

        2. Add a model definition and element definition for the new character.

        3. If the character has animations, add them to character_animations_table.mtl.

        4. Create a new VR-Forces character in the Simulation Object Editor.


        1. Copy DI-Guy Files to the Data Directory

          VR-Forces stores files for DI-Guy characters in ./data/Lifeforms/DIGuy and its subdirec- tories. After you create a new character using DI-Guy software, you must copy the files for this character to these directories.

          DI-Guy documentation recommends that all customer content be placed in

          $(DIGUY)/custom. To follow this convention, create a directory called ./data/Life- forms/DIGuy/custom and put your files in the appropriate subdirectories under it.

          VR-Forces can visualize custom DI-Guy characters based on DIS enumerations mapped to element definitions or by recognizing custom DI-Guy PDUs.

          • If you want to map your custom characters to element definitions, then you must add new simulation models in the Simulation Model Editor. This will automatically create the complementary model and element definitions and object type mappings.

          • If you want to visualize characters based on custom DI-Guy PDUs without creating element definitions or object type mappings, place the DI-Guy files in the

    ./data/Lifeforms/DIGuy/custom directory as described in the previous paragraph. No

    further configuration is needed.

    Adding DI-Guy Models to VR-Forces — DI-Guy Configuration Files

    image

    68.2. DI-Guy Configuration Files

    VR-Forces can specify the character, appearance, and animation values for DI-Guy models used in 3D visualization applications such as VR-Forces and VR-Vantage. A model’s character determines the kinds of movement it can make. The appearance determines what it looks like. The animation specifies the movements that the character makes.

    In the VR-Forces front-end, you can specify the animation with the DI-Guy Animation task. You can set the appearance with the DI-Guy Appearance set data request. For details about specifying DI-Guy characteristics in the front-end, please see “DI-Guy Animation,” on page 29-5, “DI-Guy Characteristics (Appearance, Head, Body Weight),” on page 34-16, and “DI-Guy Hand Item,” on page 34-16.

    You can specify the default character, appearance, and animation for a lifeform entity in the Simulation Object Editor. (For details, please see “DI-Guy Animation,” on

    page 29-5“Editing a Lifeform’s Visual Model and Animation,” on page 65-16.) The DI-Guy mappings are stored in the entity’s .entity file.

    The DI-Guy animations available to lifeforms are controlled by

    ./appData/settings/vrfSim/character_animations_table.mtl. This information is used to populate the lists in the Simulation Object Editor. You can edit this file to add addi- tional DI-Guy characters to those already configured for VR-Forces. The syntax of entries is described in the file.


    image

    !

    !

    Any characters you add to character_animations_table.mtl must be valid DI- Guy characters. You cannot arbitrarily make up new types of characters. If you create new characters using a supported version of the DI-Guy SDK, VR-Forces will support these characters.


    image

    Adding DI-Guy Models to VR-Forces — DI-Guy Configuration Files

    image

        1. Adding a New DI-Guy Animation

          This section explains how to add a new DI-Guy animation to VR-Forces. It assumes that you have the DI-Guy software and have created the new animation.


          image

          i

          i

          The new animation must be made with the same version of DI-Guy supported by VR-Forces. Please see VR-Forces Release Notes for the currently supported version.


          image


          To add a new DI-Guy animation:

          1. Create the new animation in DI-Guy. You will create an animation and add it to a character’s action table. Make sure that the name of the animation file matches the name of the action you added to the action table. For example, if the name of the animation is layEgg, but you call the action lay_egg, it will not work.


            image

            i

            i

            There is a 1-1 relationship between characters and their action tables. You cannot use an animation based on a chicken character in a cow character’s action table.


            image


          2. Add the motion_name.bdm file for the animation to ./data/Life- forms/DIGuy/motions.

          3. Add the action_table.cfg file to ./data/Lifeforms/DIGuy/config/diguy.

          4. Add the new animation to ./appData/settings/vrfSim/character_animations_table.mtl. This table determines whether an animation can be assigned to a character using the DI-Guy Animation task (is-taskable-animation True) or whether it is used based on the entity’s behavior. For example, if a character is moving faster than a certain speed, it is given a running animation. An entry for our lay egg example would look like the following:

    (chicken

    (display-name "Chicken") (animations

    (animation

    (animation-name "lay_egg")

    (name-to-be-displayed "Lay an egg") (is-taskable-animation True) (animation-variant "normal")

    )

    (animation

    (animation-name "feeding") (name-to-be-displayed "Feed") (is-taskable-animation True) (animation-variant "normal")

    )

    ...

    Adding DI-Guy Models to VR-Forces — Add a New DI-Guy Entity in the Simulation Object Editor

    image

      1. How VR-Forces Maps DI-Guy Models

        Ordinarily, VR-Forces chooses animations to play for a DI-Guy based on the lifeform’s speed, position, and similar attributes. However, VR-Forces can specify the DI-Guy state and appearance with the Set DI-Guy Appearance set data request and the Set DI- Guy Animation task. Once you explicitly set the DI-Guy appearance or animation, VR-Forces no longer tries to choose animations and expects to be told how to render that lifeform for the remainder of the simulation.


      2. Add a New DI-Guy Entity in the Simulation Object Editor

    Add a new entity in the Simulation Object Editor, as described in “Creating a New Simulation Object,” on page 65-32.

    When you specify the 3D model, the list of character names is drawn from the display- name attribute in the entries in ./appData/settings/vrfSim/character_animations_table.mtl. Therefore, it must have been updated before you can specify the 3D model in the Simulation Object Editor.

    Adding DI-Guy Models to VR-Forces — Add a New DI-Guy Entity in the Simulation Object Editor

    image


    image 69. The Object Parameter Database


    This chapter provides a detailed description of the object parameter database. It will be most useful to VR-Forces users who need to develop and configure new components.

    The Object Parameter Database 69-2

    VR-Forces Classes and Object Parameters 69-3

    Object Types 69-4

    Parameter Types 69-8

    Local and Remote Subcomponents 69-9

    Component Descriptors and Parameters 69-13

    Common Elements of Component Descriptors 69-13

    Configuring the Priority of Components 69-16

    Platform Files 69-16

    System Definition Files 69-17

    Creating a System Definition File 69-17

    Configuring System Connections 69-18

    Adding Variable Bindings to Platform and System Files 69-21

    Adding a Variable Binding 69-22

    Making Variables Editable in the Simulation Object Editor 69-23

    Adding Platform Variable Bindings to the Simulation Object Editor . 69-23 Adding System Definition File Variables to the Simulation Object Editor ... 69-25

    Configuring Units 69-25

    Configuring Tactical Graphics 69-26

    Pathname Interpretation in Simulation Model Set Files 69-26

    Updating Object Parameter Database Files for New Releases 69-27

      1. The Object Parameter Database

        VR-Forces simulation objects and tactical graphics have many parameters. Parameter values are stored in files organized in simulation model sets (SMS) that VR-Forces reads when you load a scenario or create new objects. We refer to these files collectively as the object parameter database (OPD). The object parameter database specifies both the characteristics of a simulation object and starting state values. You can modify the behavior of a simulation object by changing the parameters for that type of simulation object. You can add new types of simulation objects and new behaviors to VR-Forces by adding new files to the object parameter database.


        image

        !

        !

        Before you make any changes to the object parameter database, make a backup copy of the file you are changing.


        image


        Figure 69-1 illustrates the organization of an entry in the OPD. The primary definition of a simulated object, such as an entity, a tactical graphic, or a cultural feature, is stored in a file with the extension .entity. The .entity file specifies the object type enumeration, marking text, organizational information, and other parameters. It references a plat- form file (extension .ope), that provides a set of generic components for the object type, such as ground platform, surface platform, or line object. Each .entity file also specifies the systems that allow it to interact with the simulated environment, such as sensors, weapons, and movement systems.

        Systems are configured in system definition files. System definition files group related component and connection specifications into convenient packages. The components reference additional configuration files. The system definition files also make it possible to add systems to simulation objects in the Simulation Object Editor.



        weapons system (.sysdef)

        weapons system (.sysdef)

        weapons system (.sysdef)

        weapons system (.sysdef)

        image

        movement system (.sysdef)

        movement system (.sysdef)

        Platform (.ope) Object (.entity)


        weapons system (.sysdef)

        weapons system (.sysdef)

        weapons system (.sysdef)

        weapons system (.sysdef)

        damage system (.sysdef)

        damage system (.sysdef)

        weapon system (.sysdef)

        sensor system (.sysdef)


        ammo select

        (.asl)

        hit

        (.hit)

        damage

        (.dmg)

        detection

        (.csv)

        formation

        (.frm)

        ammo select

        (.asl)

        hit

        (.hit)

        damage

        (.dmg)

        detection

        (.csv)

        formation

        (.frm)


        signature rules (.mtl)

        weapons system (.sysdef)

        weapons system (.sysdef)

        weapons system (.sysdef)

        weapons system (.sysdef)

        other systems (.sysdef)



        Figure 69-1. Object definition


        1. VR-Forces Classes and Object Parameters

          When you create any simulated object in VR-Forces, an instance of DtVrfObject is created in the simulation engine. Different types of simulation objects require different parameters for simulation and publishing, which are initialized by a subclass of DtVrf- ObjectParameters, and stored in a subclass of DtVrfObjectBaseStateRepository. Each DtVrfObject “has a” DtVrfObjectParameters and a DtVrfObjectBaseStateRepository. The type of parameters object to use for simulation object creation is specified in the simula- tion object's platform file by the parameter-type parameter. The state repository is speci- fied in the state-repository parameter in the local-objects block. For example, when an entity that references the platform Ground_Vehicle.ope, which has a parameter type ground-vehicle-param, is created, a DtVrfGroundVehicleParameters object is created to read in the initial values from, and a DtGroundVehicleStateRepository is used to store runtime values.


        2. Object Types

          VR-Forces uses an eight-digit enumeration scheme for specifying objects. The enumer- ations are based on the seven-digit enumerations used by DIS and the RPR FOM. The additional field distinguishes between individual and unit objects.

          This enumeration scheme describes a tree that goes from a more general specification to a more detailed one. Figure 69-2 illustrates a partial object type tree. To build an object type enumeration, start at the Kind and work your way down the tree, adding the number for each element. So, for example, if you follow the tree down to M1A2 you build the enumeration: 1 1 225 1 1 3 0. Since M1A2 is a leaf in the tree, the last field is

          1. For more information about the object enumeration scheme, please see the SISO Enumerations Document (SISO Reference for Enumerations for Simulation Interoperability).


            (Root)

            image image

            Kind = platform (1) Kind = munition (2)

            image image image

            image

            image

            Domain = land (1) Domain = air (2) Domain = antiarmor (2) Country = US (225)

            image

            image

            image

            Category = Tank (1) Subcategory = M1Abrams (1) Specific = M1A2 (3)

            Extra = M1A2 (0)


            Figure 69-2. Object type enumeration tree


            The Object Super-Type

            VR-Forces adds a field to the standard 7-digit entity enumeration so that we can manage objects that are not part of the DIS/RPR FOM enumeration scheme, such as units and tactical graphics. We enclose the seven-digit enumeration in parentheses and preface it with the object super-type (Figure 69-3). For example, the object enumera- tion for an M1A2, described in the previous paragraph, becomes the object type: 1 (1 1 225 1 1 3 0).



            image

            (object-type 1 (1 1 225 1 1 3 0))

            image

            object super-type DIS/RPR FOM enumeration Figure 69-3. VR-Forces object-type parameter

            Table 69-1 lists the values VR-Forces can use for the object super-type. For more infor- mation, please see objTypeEnums.h or “Object Type Enumerations,” on page C-9.

            image

            Table 69-1: Object super-type field values


            Object super-type Meaning

            Object super-type Meaning

            1. Other.

            2. Individual (platform entities, individual tactical graphics).

            3. Unit.

            4. Disaggregated unit (a unit composed of other simulation objects).

            5. Aggregated unit (a unit that does not have subordinate simulation objects).

            image


            Published Object Types and Matching Object Types

            Each simulation object in the OPD has two object types – the published object type and the matching object type.

            The published object type is used as follows:

          2. The discovered object type matches the top level - any object, because all fields are wild cards.

          3. The discovered object type matches the fixed-wing object type, because the first three fields match and the rest are wild cards.

          4. The discovered object type matches the U.S. attack fixed-wing object type.

          5. The discovered object type does not match the A-10 Thunderbolt matching object type. Although the first five fields match, the sixth is different and is not wild carded.

          The best match is the U.S. attack fixed-wing object type, so VR-Forces will use the generic U.S. attack fixed-wing model to represent the discovered simulation object.


        3. Parameter Types

          In addition to specifying an object-type for each object, you must specify a parameter-type for each object. The parameter-type determines the parameters and components that can be specified for an object. For example, a rotary-wing or fixed-wing entity can have a nose-support parameter, but a ground vehicle cannot. Figure 69-4 illustrates the object parameter type hierarchy.


          vrf-base-object-param

          image

          image

          vrf-object-param moving-object-param


          image

          aggregate-object-param cultural-feature-param fixed-wing-entity-param ground-vehicle-param human-param

          missile-param

          rotary-wing-entity-param subsurface-entity-param surface-entity-param bomb-param

          global-environment-param circle-object-param

          point-object-param

          scripted-movement-object-param tactical-smoke-param


          Figure 69-4. Object parameter hierarchy

          The parameter-type specifies the set of parameters appropriate to a simulation object, and the object state repository maintains state information for a simulation object, so the parameter-type and state repository must match. For more information, please see “The State Repository Hierarchy,” on page 69-12.


          image

          i

          i

          The object-type is specified in an object’s .entity file. The parameter-type is specified in the platform (.ope) file.


          image


        4. Local and Remote Subcomponents

          As explained in “Local Objects and Remote Objects,” on page 3-9, each VR-Forces back-end simulates objects itself (local objects), and maintains state information about remote objects. All of these objects are instantiated as DtVrfObjects. The DtVrfObject class has a “has a” relationship with the following classes:

    task-manager local-task-manager

    image

    component-manager component-manager plan-manager vrfobject-plan-manager


    Every object must have a state repository specified. Objects that should be published need a net interface. Other subcomponents are optional. However, for most simulation objects, you will want to specify a task manager, plan manager, and component manager so that you can control the simulation object and give it tasks.


    The local and remote objects parameters are specified in the platform (.ope) files. There- fore they apply to all simulation objects that reference a particular platform. Use the existing entries in the object parameter database as guidance if you create a new plat- form or change an existing platform. A typical entry for local and remote objects is:

    (local-objects

    (state-repository "ground-entity-state-repository") (state-repository-min-tick-period -1.000000)

    (state-repository-min-tick-period-variance -1.000000) (net-interface "individual-local-entity-net-interface") (net-interface-min-tick-period -1.000000)

    (net-interface-min-tick-period-variance -1.000000) (task-manager "local-task-manager")

    (component-manager "component-manager") (plan-manager "vrfobject-plan-manager")

    )

    (remote-objects

    (state-repository "vrf-moving-object-state-repository") (state-repository-min-tick-period -1.000000)

    (state-repository-min-tick-period-variance -1.000000)

    (net-interface "vrf-individual-remote-entity-net-interface") (net-interface-min-tick-period -1.000000)

    (net-interface-min-tick-period-variance -1.000000) (task-manager "")

    (component-manager "") (plan-manager "")

    )


    The State Repository Hierarchy

    Each VR-Forces object must have a state repository to maintain essential state informa- tion about the object, such as its current location, orientation, appearance, and so on. Therefore, each object must specify a state repository and the state repository must match the parameter-type for the object. (The state repository and parameter-type are specified in the platform file.)

    Table 69-4 lists parameter types and the state repository type required.

    image

    Table 69-4: State repository and parameter types


    State Repository Type Parameter Type

    State Repository Type Parameter Type

    ground-entity-state-repository ground-vehicle-param fixed-wing-entity-state-repository fixed-wing-entity-param individual-lifeform-state-repository individual-lifeform-param rotary-wing-entity-state-repository rotary-wing-entity-param human-state-repository human-param

    cultural-feature-state-repository cultural-feature-param missile-entity-state-repository missile-param

    surface-entity-state-repository surface-entity-param subsurface-entity-state-repository subsurface-entity-param vrf-moving-object-state-repository moving-object-param

    vrf-overlay-object-state-repository vrf-object-state-repository

    vrf-object-param


    image


    The Net Interface Hierarchy

    VR-Forces manages network relationships of local and remote simulation objects through the network interface classes. Choose the set of local and remote network inter- face types that most closely represent the type of object being simulated. For example, for an individual vehicle such as a tank, choose individual-local-entity-net-interface for the local network interface and vrf-individual-remote-entity for the remote network interface. Please see Appendix C, Object Parameters for tables that list the network inter- faces used for the simulation objects provided with VR-Forces.


      1. Component Descriptors and Parameters

        The parameters for a simulation object include a list of all the sensor, controller, and actuator components it uses. (For details, please see “VR-Forces Uses a Component Architecture,” on page 15-8.) These components might be in the OPE file or in a system definition file. If there are no components of a certain type (for example, no sensors), you can omit the list. (In other words, you do not need a placeholder list for unused components.)

        A component descriptor is a text block in a platform or system definition file that describes a component (see Example 69.1). A component descriptor must include the type of the descriptor and the type of the component that it is describing. A component descriptor can also contain parameters for the component. “Common Elements of Component Descriptors,” on page 69-13 describes the construction of a component descriptor.

        Components can receive data from, and convey data to, other components through ports. These ports are specified in platform files and system definition files.

        A component can create a port group, which groups a set of related ports together. For example, the automotive-control port group groups the throttle, steering, and brake ports. Use of port groups simplifies specification of connections because you just have to specify a port group instead of many individual ports. For component descriptions and a list of port groups, please see the online help for the OPD Editor. For a detailed discussion of ports and port groups, please see API documentation.

        The port group also provides a mechanism for ensuring that only one data provider attempts to put values on those ports each simulation frame. For more information, please see “Configuring the Priority of Components,” on page 69-16.


        1. Common Elements of Component Descriptors

          The common elements of component descriptors are:

        2. Configuring the Priority of Components

          Each simulation frame, VR-Forces ticks each simulation object’s components in the order in which they are listed in the platform and system definition files. If a compo- nent believes it should be providing data, it takes control of the receiving component’s ports or port group. Once a component acquires the ports, no other component can send data to that component during that frame. Therefore the order in which compo- nents are listed provides a natural priority scheme.

          For example, among the ground movement controllers, the collision avoidance controller is placed on the controller list before any of the other movement controllers. If this controller needs to provide input to the ground automotive actuator to avoid a collision, it takes control of the automotive-control port group on the next tick and overrides the controller that previously owned the port group (such as Move To or Move Along).


      2. Platform Files

        Platform files (extension .ope) are the foundational configuration files for all simulated objects. They provide the basic description of each type of simulation object that you can create, such as a ground vehicle, surface vessel, or human. They also define types of tactical graphics. All platform files are part of an SMS. A platform file includes all of the components that every simulation object of that type needs to have, such as collision avoidance, radios, script controllers, and so on.

        A platform file does not include systems that vary among specific examples of the plat- form, such as weapon systems, movement systems, and damage systems.

        A platform file uses variables for the parameters that need to be different for specific examples of a platform. For example, all ground vehicles have a maximum speed, but tanks and civilian vehicles have a different value for this parameter. The values for these variables get set in the Simulation Object Editor.

        You can create and edit platform files in the OPD Editor or using a text editor. The OPD Editor is the recommended way to edit them. Platform files use MTL syntax. Most VR-Forces users will not need to create new platform files. You may need to add components or change parameters to be variables.


      3. System Definition Files

        The Simulation Object Editor allows VR-Forces users to easily add component systems, such as weapons, sensors, and movement, to simulation objects without needing to understand the components, configuration files, and connections required to make these systems work. These systems are defined in system definition files (.sysdef). System definition files are referenced in a simulation object’s .entity file. They are read by the OPD Editor and can be edited in it.

        System definition files have two major sections – data and metadata. The data is a list of the components and connections required to implement the system for a simulation object.

        The metadata explains to the Simulation Object Editor how to present the system to the user and how to integrate it into the entity model.


        1. Creating a System Definition File

          If you want to create a new system definition file, MAK recommends that you copy an existing file and use it as a template for adding the components that you want to configure into a system. You can use the OPD Editor to do this or a text editor.

          The format of a system definition file is as follows:

          (system-name (controllers

          )

          (actuators

          )

          (connections

          )

          (resources

          )

          (meta-data

          (system-name "Spot Report Generator")

          (system-description "Allows the entity to send spot reports though its radio when its sensors detect other entities in the scenario.")

          (allowed-state-repository-types "all") (system-categories "other")

          (meta-data-entry-list

          )

          (parameter-data-list

          )

          )

          )

          As you can see, system definition files use MTL syntax. (For information about MTL syntax, please see “MÄK Technologies Lisp (MTL) Files,” on page A-3.) The system- name is an arbitrary name that uniquely identifies the system. The component sections list the various controllers, actuators, sensors, and resources that are needed to build the system. The connections section lists the connections among the components.


          image

          !

          !

          You can call the system whatever you want, but the name must not start with a number.


          image


        2. Configuring System Connections

          Within each system definition file, you list the connections among the components in the file. (For general information about connections, please see “Common Elements of Component Descriptors,” on page 69-13.) For systems that are self-contained, for example movement systems, there is no need to connect to components in other systems. However, some systems need to connect to components outside their system. For example, a visual sensor needs a list of object types to detect. This section explains how to make these out-of-system connections.

          To understand how system definition files and .entity files are integrated, we will look at:

          • A componentSystem element in a .entity file.

          • The related system definition file.

          • The connection section in the system definition file.

    The M1A2, which uses the Ground_Vehicle platform, is configured with a visual sensor (in M1A2_Abrams_MBT.entity) as follows:

    1 <simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope">

    2 ...

    1. <componentSystem systemName="sensor"

      platform="@(system-dir)/sensors/visual-sensor.sysdef">

    2. <bodyPosition paramName="sensor-position" right="0.57" forward="-1.14" up="2.1"/>

    3. <real paramName="max-range">4000</real>

    4. </componentSystem>

    The sensor component references the system definition file visual-sensor.sysdef. The parameters specified provide values for the variables in the system definition file. (For more information, please see “Adding Variable Bindings to Platform and System Files,” on page 69-21.)

    The system definition file has the following connections:

    1 (visual-sensor-system 2 ...

    1. (connections

    2. (connect system:object-types-to-detect visual-sensor:object-types-to-detect)

    3. (connect visual-sensor:detected-objects system:detected-objects)

    4. (connect system:sensor-offset visual-sensor:sensor-offset) 7 )

    1. (resources )

    2. (meta-data

    3. (system-name "Visual Sensor")

    4. (system-description "Allows an entity to detect other objects through visible light.")


    5. (allowed-state-repository-types "all")

    6. (system-categories "sensor") 14 ...

    15 )

    The system definition file defines connections for its components. The first connection in the list (line 4) means that some external component (system) is providing input from its object-types-to-detect port to the visual sensor’s object-types- to-detect port. The second connection specifies that the visual sensor’s detected- objects port sends data to some external component’s detected-objects port. When VR-Forces creates a simulation object, it needs to substitute an actual compo- nent for the generic “system” component specified in the system definition file. It does this by referring to an auto-connection block in the OPE file

    The platform file has a set of auto-connection blocks like the following (from Ground_- Vehicle.ope):

    (auto-connection

    (source-controller "target-selection") (source-port-name "object-types-to-detect") (destination-category "sensor")

    (destination-port-name "object-types-to-detect")

    )

    The auto-connection block in the OPE file is a template that VR-Forces uses to match systems of a specified category to the appropriate controllers. In this example the target-selection controller sends data through its object-types-to- detect port to the object-types-to-detect port of any system that is in the sensor category. Since the visual sensor is in the sensor category, it substitutes the target-selection controller for the generic system in building its connections.

    Figure 69-5 illustrates the relationships of the OPE file, .entity file, and system defini- tion files referenced in this section and how connections are made.

    The M1A2 entity, which uses the Ground_Vehicle platform, has a visual sensor (callout 1). The visual sensor has several connections. The one illustrated in the figure (2) takes input from an external source’s object-types-to-detect port and sends it to the visual sensor’s object-types-to-detect port (3). In this connection, the external source is represented by system. Before the sensor can actually work, this unspecified system must be determined.

    When the entity is created, VR-Forces checks all the auto-connections in the OPE file (4). In this case, there is an auto-connection from the target-select controller’s object-types-to-detect port to the object-types-to-detect port of a component whose destination category is sensor (5). To make this connection, the unspecified sensor must be determined.

    VR-Forces matches the destination-category value “sensor” in the OPE file to the system-categories value “sensor” in the system definition file and the connec- tions can now be completed (6).


    image

    M1A2_Abrams_MBT.entity


    <simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope">

    <componentSystem systemName="sensor"

    platform="@(system-dir)/sensors

    /visual-sensor.sysdef

    >

    M1A2_Abrams_MBT.entity


    <simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope">

    <componentSystem systemName="sensor"

    platform="@(system-dir)/sensors

    /visual-sensor.sysdef

    >

    1 image

    image

    image

    image

    image

    image

    image

    "


    visual-sensor.sysdef

    image

    1. (connect system:object-types-to-detect

      image

      visual-sensor:object-types-to-detect)

      image

      (system-categories "sensor")


      image

      image

      system

      object-types-to-detect

      system

      object-types-to-detect

      visual sensor

      image

      image

    2. object-types-to-detect


      image


      image

      image

      Ground_Vehicle.ope

      image

      (auto-connection

      (source-controller "target-selection")

      image

      (source-port-name "object-types-to-detect") image

      image

      image

    3. (destination-category "sensor") (destination-port-name

    "object-types-to-detect")

    )



    image

    sensor

    object-types-to-detect

    sensor

    object-types-to-detect

    target-selection

    5

    object-types-to-detect


    image

    image

    target-selection

    object-types-to-detect

    target-selection

    object-types-to-detect

    visual sensor

    object-types-to-detect

    visual sensor

    object-types-to-detect

    6


    Figure 69-5. External component connection


    image

    i

    i

    Most VR-Forces users add new systems by copying existing ones and changing their parameters. If you add new systems in this way, you will not need to worry about adding connections, since the existing auto-connection system will handle them automatically. If developers add new types of components that require intersystem connections, they will need to add new auto-connection blocks to the appropriate OPE files for them to connect.


    image


      1. Adding Variable Bindings to Platform and System Files

        Platform files and most system definition files are used by multiple simulation objects. However, the values of some parameters may need to vary for the different simulation objects that use them. This is handled by using variables in the platform and system definition files and specifying the values for these variables in the .entity files. VR-Forces uses variable bindings for the parameters that you are most likely to want to change from simulation object to simulation object. If there are other parameters that you want to vary, you can add your own variable bindings.

        When you add a variable binding, you must:

        1. Change the hard-coded value to a variable in the platform or system definition file.

        2. Add the variable to the .entity file.

        3. Update the Simulation Object Editor so that you can edit the value for the new variable.

    The following example shows a variable binding for fuel in a movement system. The variable is specified in the system definition file as follows:

    (resources (fuel

    (resource-type "real-resource") (amount $fuel-amount)

    (full-amount $fuel-amount)

    )

    )

    The .entity file for a simulation object that uses this movement system specifies a value for the variable:

    <componentSystem systemName="movement"

    platform="@(system-dir)/movement/ground-tracked.sysdef">

    <real paramName="fuel-amount">465</real>

    </componentSystem>

    As you can see, the parameter defined as fuel-amount in the .entity file is referenced as

    $fuel-amount in the system definition file.


        1. Adding a Variable Binding

          The procedure for adding a variable binding is the same for platform files and system definition files.

          To add a variable binding to a platform file or system definition file:

          1. In the system definition file, substitute a variable name, in the format $variable- name for the hard-coded value that you want to replace. For example, the Ground_- Vehicle.ope file has a value is-organized:

            (groundParams

            (is-organized True)

            )

            To make this a variable, replace the value with a variable name, as follows:

            (groundParams

            (is-organized $entity-is-organized)

            )

            You can do this by hand in the OPE file or in the OPD Editor.

          2. Optionally, specify a default value for the variable. The default value is used if no value is specified for an entity type that uses this OPE file. The syntax for speci- fying a default value is:

            (default “value”)

            In this example, to set the default value to True, do the following:

            (groundParams

            (is-organized $entity-is-organized (default “True”))

            )

          3. In each .entity file that uses this platform file or system definition file, add an element to specify a value for the variable. The attribute must specify the type of the value, the name of the variable, and the value for the variable, for example.

            <simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope">

            <bool paramName=”entity-is-organized”>True</bool>

            ...

            </simObject>

            Although you can add these entries by hand, it is highly recommended that you do so in the Simulation Object Editor by applying platform updates. When you apply platform updates, all changes to platform and system definition files get applied to all simulation objects that use them. For details, please see “Applying Platform Updates,” on page 64-19.


            image

            !

            !

            If you do not add an attribute to an .entity file that references the modified platform or system definition file, a default value will be used, which may result in unexpected behavior.


            image


        2. Making Variables Editable in the Simulation Object Editor

          When you add new variable bindings, you can make them editable in the Simulation Object Editor. Variables in platform files are edited in the Attributes panel (the right- most panel) of the Simulation Object Editor. They include variables such as speed, mass, and bounding volume. Variables in system definition files are edited in the Prop- erties dialog boxes for the individual systems. The procedures for adding these two types of variables to the Simulation Object Editor are different.


        3. Adding Platform Variable Bindings to the Simulation Object Editor

          Variable bindings for platform files are edited in the Attributes Panel. The layout of this panel is controlled by .ui files. The Simulation Object Editor has a .ui file for each plat- form. The files are in ./data/simulationModelSets/<model_set>/gui/ui. You can edit .ui files in a text editor or in Qt Designer.


          image

          i

          i

          You do not need a developers license to use Qt Designer. You will need to download the version of Qt used by your version of VR-Forces. Please see VR-Forces 4.5 Release Notes for details.


          image


          In “Adding Variable Bindings to Platform and System Files,” on page 69-21, we added a new variable binding to the Ground_Platform.ope file. The corresponding entry in ground-vehicle-param.ui file would be:

          <item>

          <widget class="QCheckBox" name="entity_is_organized">

          <property name="text">

          <string>Is Organized</string>

          </property>

          </widget>

          </item>

          Notice that the variable name entity-is-organized in the OPE file is expressed as enti- ty_is_organized in the .ui file. You must use underscores in the .ui file for the variable name.


          UI File Details

          Whether you edit a .ui file by hand or using Qt Designer, you need to understand how data entry elements are defined. This varies depending on the type of widget used, such as text box, check box, option button, or list.

          It is beyond the scope of this manual to explain Qt Designer and GUI layout. However, at the most basic level, the controls in the GUI are specified in item elements. Each item has a widget that has a class and an objectName. (The XML attribute is name. In Qt Designer it is objectName.)

          The Object Parameter Database — Configuring Units

          image


          <signal>;<referencedControl>;<slot>released();bounding_volume; onCalculateSupportPointsChanged()

          The referenced control is the name of an existing control in the .ui file.


        4. Adding System Definition File Variables to the Simulation Object Editor

    When you add a system to a simulation object in the Simulation Object Editor, you can edit its properties. The Properties dialog box is not configured in a .ui file. It is gener- ated based on the metadata section of the system definition file. Suppose that you want to change the rounds per minute parameter in 120mm-gun.sysdef to a variable binding. You would create the variable binding as described in “Adding Variable Bindings to Platform and System Files,” on page 69-21 and you would add details to the metadata as shown in the following example:

    (weapon-120mm-gun

    ...

    (rounds-per-minute $rounds-fired-per-minute)

    ...

    (meta-data

    (parameter-data-list (bool-parameter-data

    (parameter-name "rounds-fired-per-minute") (variable-type "DtRwInt")

    (display-label "Rounds Fired Per Minute") (display-units "")

    (source-units "") (default-value True)

    )

    ...


      1. Configuring Units

        All units have the parameter-type aggregate-object-param.

        In entity-level scenarios, most functionality resides in entities and units have relatively few individual parameters. The principle function of the various elements is to specify controllers and formations, and to specify the echelon-level for the different levels of units.

        In aggregate-level scenarios, aggregated units can have many systems and parameters. Disaggregated units, like their entity-level counterparts, have limited capabilities. Both types of unit have the parameter-type aggregate-object-param.

        The Object Parameter Database — Configuring Tactical Graphics

        image

      2. Configuring Tactical Graphics

        The object parameter database includes parameters for tactical graphics. Tactical graphics provided with VR-Forces have the parameter-type vrf-base-object-param. You should not change the parameters for the objects provided with VR-Forces. However, if you are using the VR-Forces toolkit, you could create other types of tactical graphics. You would have to include parameters for them in the object parameter database.


      3. Pathname Interpretation in Simulation Model Set Files

        The files that make up a simulation model set, such as .entity files and system definition files, usually contain references to other files in the SMS. These supporting files may also have references to other configuration files. VR-Forces supports the file relation- ships by specifying files using relative paths and by defining directory variables. This allows you to maintain custom simulation model sets outside of the VR-Forces file hier- archy and not have to move them every time you install a new version of VR-Forces.

        Examples of directory variables are in the SMS file and OPD file. The following lines from the EntityLevel.sms file show a binding (model-set-directory) and its use:

        (simulation-model-set (variable-bindings

        (DtRwString

        (model-set-directory "EntityLevel")

        )

        (DtRwString

        (opd-dir "$(model-set-directory)")

        )

        ...

        )

        (opd-file "$(model-set-directory)\vrfSim.opd")

        (physical-world "$(model-set-directory)\physicalWorldParams.mtl")

        ...

        )

        Similarly, the vrfSim.opd file has bindings, which are then used in .entity files, as shown. From vrfSim.opd:

        (variable-bindings (DtRwString

        ...

        (system-dir "$(opd-dir)/vrfSim/systems"

        )

        (DtRwString

        (ammoselect-dir "$(opd-dir)/vrfSim/ammoselect"

        )

        ...

        )

        From M1A2_Tank.entity (system-dir variable):

        <componentSystem systemName="damage"

        platform="@(system-dir)/damage/ground-heavy-armor.sysdef"/>

        The Object Parameter Database — Updating Object Parameter Database Files for New Releases

        image

      4. Updating Object Parameter Database Files for New Releases

        New releases of VR-Forces frequently include new components and new parameters for existing components. If you are using a customized SMS you will probably want to update it to take advantage of the new components and parameters. Unfortunately, there is no automatic way to migrate an object parameter database. Here are some guidelines and options for migrating your SMS:

    The Object Parameter Database — Updating Object Parameter Database Files for New Releases

    image


    image 70. Using the OPD Editor


    This chapter describes how to use the OPD Editor to edit simulation model sets (SMS).

    The Object Parameter Database Editor 70-2

    Starting the OPD Editor 70-2

    Loading a Simulation Model Set 70-3

    Editing Platforms and Systems 70-4

    Creating a New Platform or System from an Existing One 70-4

    Editing Individual Parameters 70-6

    Deleting Parameters and Components 70-7

    Restoring Parameters 70-7

    Adding New Components and Parameters 70-8

    Adding New Components 70-8

    Changing A Component’s Priority 70-9

    Creating A Connection 70-10

    Adding New Resource Parameters 70-11

    Editing Variables 70-11

    Regenerating Platform Files 70-12

    Saving Changes to the Object Parameter Database 70-12

    Using the OPD Editor — The Object Parameter Database Editor

    image

      1. The Object Parameter Database Editor

        The Object Parameter Database Editor (OPD Editor) is a graphical user interface for editing platforms and systems. When you use the OPD Editor instead of a text editor, you do not have to worry about getting MTL or XML syntax correct in your files. It also quickly gives you access to all the platforms and systems without needing to know which particular files they use.

        If you want to edit or add simulation objects, use the Simulation Object Editor.


      2. Starting the OPD Editor

        To start the OPD Editor, on the Start menu, choose MÄK Technologies VR- Forces 4.5 Tools OPD Editor. The OPD Editor opens (Figure 70-1).


        image

        Figure 70-1. OPD Editor

        To start the OPD Editor from the Windows or Linux command line:

        1. Change directory to ./bin64.

        2. Run vrfOpdEditor.

          Using the OPD Editor — Loading a Simulation Model Set

          image

      3. Loading a Simulation Model Set

        To edit a simulation model set, you must load it into the editor.

        To load a simulation model set:

        1. Choose File Open Simulation Model Set. An Open dialog box opens. By default it opens to ./data/simulationModelSets.

        2. Select the SMS you want to load, for example, EntityLevel.sms.

        3. Click Open. The SMS is loaded. Platforms are listed on the Platforms tab, systems on the Systems tab.


          image

          Figure 70-2. OPD Editor with SMS file loaded


      4. Editing Platforms and Systems

    Platforms and systems are similar in organization and construction. They simply configure objects at different levels. They have a set of general parameters, components, and possibly resources, signatures, subordinate objects, and a soil list. These parameters are organized into tabs. Within each tab, the parameters and their values are listed.

    This section explains how to edit an object’s parameters, how to delete parameters, and how to restore parameters that you have changed or deleted.

    Parameter definitions are documented by component in the online help for the OPD Editor in the Object Parameter Descriptions folder. Individual parameter definitions are displayed in the Parameter Reference panel of the OPD Editor. The definitions are also in the header files and class documentation.


        1. Creating a New Platform or System from an Existing One

          You can add new platforms and systems to the object parameter database using an existing one as a template.

          To add a new platform based on an existing platform:

          1. Select the platform on which you want to base the new one.

          2. Choose Platforms Create Platform From Existing. The Create New Platform dialog box opens.

          3. Type a name for the new platform.

          4. Click OK.

          5. Edit the parameters.

          6. Save the object parameter database.


            To add a new system based on an existing system:

            1. Select the system on which you want to base the new one.

            2. Choose Systems Create System From Existing. The Create New System dialog box opens.

            3. Type a new name for the system definition file or click Browse and select an existing file name.

            4. Type a name for the new system.

            5. Optionally, specify configuration files to copy:

              1. Click the >>> button. The dialog box expands to display the Copy Files group box.

              2. Select the file types that you want to copy.

            6. Click OK.

            7. Edit the parameters.

            8. Save the object parameter database.


        2. Editing Individual Parameters

          The various parameters in the object parameter database are all edited essentially the same way. A parameter’s value is a number or string that you type, a value that you select from a list, or a filename that you edit by hand or select from a file chooser. When you edit a parameter, the name of the parameter and all its parents are displayed in bold (Figure 70-3).



          image

          Figure 70-3. Parameter hierarchy after edits

          To edit a parameter:

          1. Select the parameter by clicking in the Name or Value column. The Value field becomes editable.

          2. Enter the new value. In most cases you enter a new value by typing it. If a param- eter value has a File Chooser button (Figure 70-4), click the button to open a File Chooser dialog box. If the value has an Edit button, click the button to open a window that allows you to edit the file.



            image

            File Chooser Edit

            Variable State Restore


            Figure 70-4. Parameter value buttons


        3. Deleting Parameters and Components

          The parameters on the General tab cannot be deleted. Parameters on the other tabs can be deleted.

          To delete a parameter or component:

          1. Select the parameter or component in the Value list.

          2. Click the Delete button at the right end of the parameter entry (Figure 70-5).


            image

            Delete

            Figure 70-5. Delete button


        4. Restoring Parameters

          If you change a value or delete a parameter or component, you can restore the original value. You can restore at the individual parameter level and at any level in a given hier- archy of entries (Figure 70-3). For example, you can restore a change to the at-distance parameter for the move-to controller, all edits made to the move-to controller, or all edits made to all Controllers. However, since Actuators are not part of the Controllers hier- archy, restoring a change at the Actuators level would not affect changes to Controllers.

          To restore a parameter or component:

          1. Select the parameter to restore. If you are restoring a deleted parameter or compo- nent, select the parent component.

          2. Click the Restore button (Figure 70-4).

          3. To undo all changes to a platform or system, choose Platforms Restore Platform

    or Systems Restore System.


      1. Adding New Components and Parameters

        You cannot add new parameters to the General tab. You can add new components, resources, subordinates, and signatures if an object supports them.


        image

        i

        i

        For most platforms, the Components tab does not list all of the components that apply to the entity. This is because many components are referenced through the systems that are attached to an instance of a platform. If you do not see a component that you are looking for in a platform’s component list, look at the component list for the relevant system in the Systems list.


        image


        1. Adding New Components


          image

          i

          i

          Before you add a component to a platform, consider whether or not the component should be added as part of a new or existing system, rather than being added directly to the platform.


          image


          To add a component to a platform:

          1. Select the Components tab.

          2. Select the component type (Actuator, Controller, Sensor) you want to add.

          3. Click the Add button (Figure 70-6). The Create New Component dialog box opens. The Component list lists all components that are available for this object.


            image

            Figure 70-6. Add button

          4. From the Component list, select the component you want to add.

          5. Click OK. The component is added to the object.

            Using the OPD Editor — Adding New Components and Parameters

            image

        2. Changing A Component’s Priority

          When you change a component’s priority, the other components are reprioritized as needed. All affected components are listed in bold.

          To change a component’s priority:

          1. Select the component you want to edit.

          2. Click the up or down arrow on the value line (Figure 70-7).


            image

            Change Priority Figure 70-7. Change Priority buttons


        3. Creating A Connection

          When you add a component, you must also add connections between the component and other components it interacts with.

          To add a connection:

          1. On the Components tab, select Connections.

          2. Click the Add button (Figure 70-6). The Create Connection dialog box opens (Figure 70-8).


            image

            Figure 70-8. Create Connection dialog box

          3. Choose a source component from the Source list.

          4. Enter the port group for the source component. You must know the name of the port group you need to use. For a list of components and port groups, see the online help.

          5. Choose the destination component from the Destination list.

          6. Enter the port group for the destination component. You must know the name of the port group you need to use.

          7. Click OK. The connection is added to the Connections list.

            Using the OPD Editor — Editing Variables

            image

        4. Adding New Resource Parameters

          To add a resource parameter to an object:

          1. Select the Resources tab.

          2. Select Resources.

          3. Click the Add button (Figure 70-6). The Create Resource dialog box opens.


            image

            Figure 70-9. Create Resource dialog box

          4. In the Resource Name box, enter the name of the resource you want to add. Resource names must start with a letter, not a number. You are responsible for knowing that this is a valid resource supported by your implementation of VR- Forces.

          5. In the Full Amount box, enter the amount of the resource to assign to this object.

          6. Select a resource type from the Resource Type list.

          7. Click OK. The resource is added to the object.


              1. Editing Variables

                The object parameter database uses variables to specify the location of supporting files, such as ammo selection files, system definition files, and formation files. You can edit these variables. (For information about variables, please see “Adding Variable Bindings to Platform and System Files,” on page 69-21.)

                To edit variables:

                1. Select the platform whose variables you want to edit.

                2. Choose Platforms Edit Variables. The Edit Variables dialog box opens.

                3. Change the variable values as desired.

                4. Click OK.

                  Using the OPD Editor — Regenerating Platform Files

                  image

              2. Regenerating Platform Files

                If a developer adds new parameters to a component that need to be set in a platform file, the parameters need to be added to the platform file. The OPD Editor can add new parameters to all platform files in one operation.

                To regenerate platform files, choose Platforms Regenerate Platform Files.


              3. Saving Changes to the Object Parameter Database

            To save an edited object parameter database, choose File Save.


            image

            1. Configuring Sensors


              This chapter explains how to configure sensors and sensor signatures.

              Configuring Sensors 71-2

              Adding a New Sensor to a Simulation Object 71-2

              Editing a Sensor System Definition File 71-4

              Specifying a Sensor Signature 71-5

              Adding Detection Types or Why Doesn’t My Sensor Detect Anything? 71-9 Adding a New Sensor Type 71-9

              Illumination and Time of Day 71-12

              Detection Tables 71-14

                1. Configuring Sensors

                  VR-Forces includes several sensor systems and you can add them to simulation objects using the Simulation Object Editor. This section provides additional details about how sensors are configured. A complete sensor configuration requires the following:

                  • One or more componentSystem elements in the .entity file for sensor systems.

                  • A list of sensor signature values in the .entity file for the sensor types that can detect the entity type.

                  • A signature propagator entry in the ./data/simulationModelSets/<model_set>/physi- calWorldParam.mtl file (one per sensor type).

              VR-Forces includes sensors such as radar, infrared, visual, magnetic anomaly detector (MAD), and sonar. The simulation objects configured in the object parameter database are configured with appropriate sensors and sensor signatures. For details about sensor components and how they work, please see API documentation.


                  1. Adding a New Sensor to a Simulation Object

                    It is recommended that you use the Simulation Object Editor to add new sensors to a simulation object. If you want to do it manually, you can edit its .entity file.

                    All sensors provided with VR-Forces are signature-object-sensors. They are distin- guished by the domain in which they operate (for example, visual, radar, infrared, MAD, or sonar).

                    To add a sensor to a simulation object by editing its .entity file:

                    1. Copy an existing componentSystem element in the .entity file and paste it into the file.

                    2. Change the systemName to be unique, for example, sensor-2.

                    3. Change the name of the system definition file to point to the sensor you want to add.

                    4. Change the values for the variables that must be specified for the sensor.


                      Connecting a Sensor

                      If you add a sensor that has been configured to use the auto-connection feature (all sensors provided by MAK support auto-connections), its connections are handled auto- matically. (For details, please see “Configuring System Connections,” on page 69-18.)

                      If you add a new type of sensor, you must connect it to input through its input port and then send the data to its output port for the appropriate controller. The sensor gets input through its object-types-to-detect input port. It sends that data out through its detected-objects output port. The connections for the visual sensor, in visual- sensor.sysdef are:

                      (connect system:object-types-to-detect visual-sensor:object-types-to- detect)

                      (connect visual-sensor:detected-objects system:detected-objects) (connect system:sensor-offset visual-sensor:sensor-offset)

                      If you were to create an acoustic sensor, its connections would look like this:

                      (connect system:object-types-to-detect acoustic-sensor:object-types-to- detect)

                      (connect acoustic-sensor:detected-objects system:detected-objects) (connect system:sensor-offset acoustic-sensor:sensor-offset)


                  2. Editing a Sensor System Definition File

                    The preferred method for editing a sensor system definition file, as with all system defi- nition files, is to edit it in the OPD Editor. You can also edit the file by hand. The following example is from the visual sensor system definition file:

                    (visual-sensor

                    (component-descriptor-type "signature-sensor-descriptor") (component-type "signature-sensor")

                    (min-tick-period 2.000000)

                    (min-tick-period-variance 0.100000) (tick-period-uses-real-time False) (process-state-repository-name "") (process-state-repository-type "") (is-enabled True)

                    (detect-only-hostile-forces False) (detection-types )

                    (detect-destroyed-objects False) (sensor-geometry

                    (in-range

                    (range $max-range)

                    )

                    )

                    (sensor-domain "visual")

                    (sensor-offset $sensor-position) (sensor-positional-error 0.000000) (detection-level-determinator

                    (determinator-type "signature-detection-level-determinator") (detection-level-to-set-hostility 3)

                    (combat-identification-level-table-file

                    "$(detection-dir)\std-visual-detection-table.csv")

                    )

                    )

                    )

                    (controllers

                    )

                    (actuators

                    )

                    (connections

                    (connect system:object-types-to-detect visual-sensor:object-types-to-detect)

                    (connect visual-sensor:detected-objects system:detected-objects) (connect system:sensor-offset visual-sensor:sensor-offset)

                    )

                    As you can see from viewing the file, most of the parameters that you would want to vary from entity to entity are variables whose values are set in the .entity file.


                  3. Specifying a Sensor Signature

                    A sensor signature indicates that a simulation object can be detected by other simula- tion objects that have a sensor for that signature. The value of the signature represents the maximum distance, at which the entity can be detected. However, this value is affected by modifiers and the calculations made by the propagator. (Technically, the signature does not assume a particular measurement unit. As implemented, distance is measured in kilometers.)

                    The modifiers specify multipliers for the base value, based on the current state of the object. For example, a simulation object might have a base value of 5.0 for its visual signature, and a modifier of 1.5 when moving. This means the signature of the entity is

                    7.5 when moving and 5.0 when not moving.

                    The following is the sensor signature block from a DI with M4:

                    (sensor-signatures (visual

                    (base-signature $visual-signature) (modifiers

                    (file

                    (external-file

                    (filename "signatureRules/lifeform-visual-rules.mtl")

                    )

                    )

                    (file

                    (external-file

                    (filename "signatureRules/visual-illumination-rules.mtl")

                    )

                    )

                    )

                    )

                    (infrared

                    (base-signature $infrared-signature) (modifiers )

                    )

                    (radar

                    (base-signature $radar-signature) (modifiers )

                    )

                    )

                    This sensor-signature block shows that a DI M4 can be detected by visual, infrared, and radar sensors. The base-signature values are variables. Their values come from the .entity file.

                    <sensorSignatures>

                    <real paramName="visual-signature">1.2</real>

                    <real paramName="infrared-signature">1.2</real>

                    <real paramName="radar-signature">0.25</real>

                    </sensorSignatures>


                    The visual sensor has two modifiers. The file lifeform-visual-rules.mtl is as follows:

                    (signature-modifiers (speed-less-than (speed 1.0)

                    (multiplier 0.5)

                    )

                    )

                    This indicates that if the entity’s speed is less than 1 KMH, multiply the base signature by 0.5. A slowly moving entity is less likely to be seen.

                    For details about the visual illumination rules modifier, please see “Illumination and Time of Day,” on page 71-12.

                    If you do not want a simulation object to be detectable by a particular type of sensor, remove the sensor signature from the .entity file. If you want it to be detectable by an additional sensor type, add its sensor signature to the .entity file. You can edit the values of sensor signatures in the Simulation Object Editor. You cannot add sensor signatures in the Simulation Object Editor. You can edit the values of sensor-signatures and add new sensor signatures in the OPD Editor.

                    Table 71-1 lists the sensor signatures that VR-Forces uses for general categories of simu- lation objects in EntityLevel.sms. (These categories do not match the categories list in the Simulation Object Editor. They represent a more granular approach to categorizing simulation objects for the purpose of applying a consistent set of sensor signatures.)

                    Table 71-1: Entity-level sensor signatures (Sheet 1 of 3)


                    Entity Category (with example)

                    Visual

                    Radar

                    Infrared

                    Sonar Active

                    Sonar Passive

                    MAD

                    Military Fixed Wing

                    - stealth technology

                    2.5

                    4

                    6

                    N/A

                    N/A

                    N/A

                    Military Fixed Wing

                    - Large Jet (Cargo)

                    7

                    30

                    30

                    N/A

                    N/A

                    N/A

                    Military Fixed Wing

                    - Small Jet (Fighter)

                    4

                    6

                    20

                    N/A

                    N/A

                    N/A

                    Military Fixed Wing

                    - Large Prop

                    5

                    25

                    15

                    N/A

                    N/A

                    N/A

                    Military Fixed Wing

                    - Small Prop

                    4

                    20

                    15

                    N/A

                    N/A

                    N/A

                    Military Fixed Wing

                    - Large UAV (Pred- ator)

                    5

                    20

                    16

                    N/A

                    N/A

                    N/A

                    Military Fixed Wing

                    - Small UAV

                    2

                    2

                    1.5

                    N/A

                    N/A

                    N/A

                    Military Fixed Wing

                    - Micro UAV (Hand Launch)

                    1

                    0.5

                    0.5

                    N/A

                    N/A

                    N/A


                    Table 71-1: Entity-level sensor signatures (Sheet 2 of 3)


                    Entity Category (with example)

                    Visual

                    Radar

                    Infrared

                    Sonar Active

                    Sonar Passive

                    MAD

                    Civilian Fixed Wing - Large (Passenger)

                    10

                    40

                    35

                    N/A

                    N/A

                    N/A

                    Civilian Fixed Wing - Medium (regional)

                    7

                    30

                    30

                    N/A

                    N/A

                    N/A

                    Civilian Fixed Wing - Small (Cesna)

                    5

                    20

                    12

                    N/A

                    N/A

                    N/A

                    Small Rotary Wing

                    4

                    20

                    20

                    N/A

                    N/A

                    0.3

                    Medium Rotary Wing

                    5

                    25

                    25

                    N/A

                    N/A

                    0.3

                    Large Rotary Wing

                    7

                    30

                    30

                    N/A

                    N/A

                    0.3

                    Military/Civilian Large Cargo Ship (tanker/cargo)

                    35

                    40

                    30

                    10

                    8

                    N/A

                    Military Aircraft Carrier

                    35

                    40

                    30

                    10

                    8

                    N/A

                    Military Cruiser

                    25

                    30

                    25

                    8

                    6

                    N/A

                    Military Destroyer

                    20

                    28

                    25

                    8

                    6

                    N/A

                    Military Frigate

                    18

                    25

                    25

                    8

                    6

                    N/A

                    Military Large Patrol (Corvette)

                    18

                    25

                    25

                    6

                    4

                    N/A

                    Military Small Patrol (covered)

                    10

                    25

                    25

                    3

                    2

                    N/A

                    Military Small (zodiac)

                    4

                    6

                    8

                    2

                    1.5

                    N/A

                    Civilian Large Commercial Passenger (Cruise)

                    45

                    50

                    50

                    10

                    8

                    N/A

                    Civilian Medium Commercial

                    25

                    40

                    35

                    8

                    5

                    N/A

                    Civilian Small Commercial (tug)

                    15

                    30

                    35

                    4

                    3

                    N/A

                    Civilian Private Medium

                    15

                    25

                    25

                    4

                    3

                    N/A

                    Civilian Private Small (24->30ft day cruiser)

                    10

                    25

                    25

                    3

                    2

                    N/A

                    Civilian Private Micro (jet ski)

                    5

                    9

                    10

                    1

                    2

                    N/A


                    Table 71-1: Entity-level sensor signatures (Sheet 3 of 3)


                    Entity Category (with example)

                    Visual

                    Radar

                    Infrared

                    Sonar Active

                    Sonar Passive

                    MAD

                    Civilian Sailboat (J-24)

                    15

                    20

                    10

                    2

                    0.5

                    N/A

                    Small Lifeboat (bright colors)

                    7

                    12

                    15

                    1

                    1

                    N/A

                    Large Lifeboat (bright colors)

                    10

                    15

                    15

                    1

                    1

                    N/A

                    Military Submarine - Large (Ohio)

                    2

                    3

                    2

                    1

                    0.01

                    N/A

                    Military Submarine - Medium (LA)

                    1.5

                    3

                    2

                    0.75

                    0.01

                    N/A

                    Military Submarine - Small

                    1.5

                    3

                    2

                    0.5

                    0.25

                    N/A

                    Military Submarine - Torpedo (non decoy)

                    0

                    0

                    0

                    1

                    2

                    N/A

                    Human (no camou- flage)

                    1.2

                    0.25

                    1.2

                    N/A

                    N/A

                    N/A

                    Human (with camouflage)

                    0.5

                    0.25

                    0.75

                    N/A

                    N/A

                    N/A

                    Human in Water (with bright vest)

                    2

                    2

                    1.5

                    N/A

                    N/A

                    N/A

                    Human in Water (no vest)

                    0.75

                    2

                    1.5

                    N/A

                    N/A

                    N/A

                    Civilian Passenger Car

                    4

                    0.5

                    4

                    N/A

                    N/A

                    N/A

                    Civilian Truck/Bus

                    6

                    1

                    6

                    N/A

                    N/A

                    N/A

                    Military Artillery - large

                    3

                    0.75

                    4

                    N/A

                    N/A

                    N/A

                    Military Artillery - small

                    1

                    0.5

                    2

                    N/A

                    N/A

                    N/A

                    Military Large vehicle (Logistics)

                    5

                    1

                    5

                    N/A

                    N/A

                    N/A

                    Military Medium vehicle (Tank)

                    3

                    0.5

                    4

                    N/A

                    N/A

                    N/A

                    Military Small vehicle (Jeep/Tech- nical)

                    1

                    1

                    2

                    N/A

                    N/A

                    N/A

                    Military Micro vehicle (human sized or smaller)

                    0.5

                    0.25

                    1

                    N/A

                    N/A

                    N/A


                  4. Adding Detection Types or Why Doesn’t My Sensor Detect Anything?

                    Sometimes VR-Forces users add a sensor to a simulation object and then wonder why it doesn’t detect anything. This problem occurs when a simulation object does not have a weapon. In this case, the sensor’s types-to-detect parameter is empty. To have a simulation object that does not have a weapon detect other simulation objects, specify object types to detect in the detection-types parameter in the sensor’s system defi- nition file, for example:

                    (detection-types

                    (entity-type 1 (1 3 -1 -1 -1 -1 -1))

                    (entity-type 1 (1 4 -1 -1 -1 -1 -1))

                    )


                  5. Adding a New Sensor Type

                    You can easily add new sensor types to your simulation objects. Suppose that you want to add an acoustic sensor. You would do the following:

                    1. Add a block to the signature-propagator-params block in physicalWorldParams.mtl.

                    2. Add a sensor componentSystem element to each entity that can detect targets acoustically.

                    3. Add a sensor signature to each simulation object that can be detected acoustically.


                      Configuring a Signature Propagator

                      The physicalWorldParams.mtl file specifies the list of sensors available and the propa- gator to use for each. The following is a portion of this file:

                      (physical-world-params (signature-propagator-params

                      (radar

                      (propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "standard-propagator")

                      (check-line-of-sight True)

                      )

                      (visual

                      (propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "visual-propagator")

                      (check-line-of-sight True)

                      ...

                      )

                      )

                      )


                      If you edit the file to add an acoustic sensor, it might look like the following:

                      (physical-world-params (signature-propagator-params

                      (visual

                      (propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "visual-propagator")

                      (check-line-of-sight True)

                      )

                      (acoustic

                      (propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "standard-propagator")

                      (check-line-of-sight False)

                      )

                      ...

                      )

                      )

                      You do not have to be able to see a simulation object to hear it, so you do not need to check line of sight.


                      Adding a Sensor Component

                      To add a new sensor component, follow the procedure in “Adding a New Sensor to a Simulation Object,” on page 71-2. A new acoustic sensor might look like the following:

                      (acoustic-sensor

                      (component-descriptor-type "signature-sensor-descriptor") (component-type "signature-sensor")

                      (min-tick-period 2.000000)

                      (min-tick-period-variance 0.100000) (tick-period-uses-real-time False) (process-state-repository-name "") (process-state-repository-type "") (detect-only-hostile-forces False) (detection-types )

                      (detect-destroyed-objects False) (sensor-geometry

                      (in-range

                      (range $max-range)

                      )

                      )

                      (sensor-domain "acoustic") (sensor-offset $sensor-position)

                      (sensor-positional-error 0.000000) (detection-level-determinator

                      (determinator-type "signature-detection-level-determinator") (detection-level-to-set-hostility 3)

                      (combat-identification-level-table-file

                      "$(detection-dir)\std-acoustic-detection-table.csv")

                      )

                      )

                      )

                      (controllers

                      )

                      (actuators

                      )

                      (connections

                      (connect system:object-types-to-detect acoustic-sensor:object-types-to-detect)

                      (connect acoustic-sensor:detected-objects system:detected-objects)

                      )


                      image

                      !

                      !

                      You can call the sensor whatever you want, but the name must not start with a number.


                      image


                      Adding a Sensor Signature

                      If you add a new sensor, you need to add a signature for it to each simulation object that can be detected by the sensor. If you add an acoustic sensor, a sensor signature might look like the following:

                      (sensor-signatures (visual

                      (base-signature 4.000000) (modifiers )

                      )

                      (acoustic

                      (base-signature 2.000000) (modifiers )

                      )

                      ...

                      )

                      You can probably see simulation objects at a greater distance than you can hear them, so the acoustic sensor has a lower base-signature value than the visual sensor.


                  6. Illumination and Time of Day

              Visual sensors take into account the time of day. They do this through an illumination value that modifies the visual sensor signature. The modification value is configured in

              ./data/simulationModelSets/<model_set>/vrfSim/signatureRules/visual-illumination-

              rules.mtl:

              (signature-modifiers (environmental

              (modifier-coefficients 1.0 0.1)

              )

              )

              “Specifying a Sensor Signature,” on page 71-5 shows how this file can be referenced in a sensor signature. Given this file, the modifier coefficients are applied to the illumina- tion value, as follows:

              Multiplier = 1.0 * illumination + 0.1

              The illumination value is derived from the time of day based on parameters in Global- Environment.ope:

              ...

              (actuators

              (global-environment-actuator

              ...

              (sunrise-time 21600.000000)

              (sunset-time 64800.000000)

              (daylight-illumination 1.000000)

              (night-illumination 0.100000)

              (day-night-transition-time 7200.000000)

              )

              )


              where:

              • sunrise-time is the time at which the daylight model changes from night to day, in seconds past midnight.

              • sunset-time is the time at which the daylight model changes from day to night, in seconds past midnight.

              • daylight-illumination is the percent illumination during the full daylight hours.

              • night-illumination is the percent illumination during the full night hours.

              • day-night-transition-time is the period of time, centered on sunrise and sunset times, where the illumination value transitions from daylight to night, or night to daylight. During this time period, the illumination level is a linear progression between the night and daylight illumination levels.

              Configuring Sensors — Detection Tables

              image

                1. Detection Tables

                  The detection tables determine the level of knowledge that a simulation object has of detected simulation objects. The detection level is used in the Detect Entity condition in plans.

                  Detection tables are comma-delimited files that are most easily read in a spreadsheet. As illustrated in Figure 71-1, each column represents a detection interval, in seconds, from 0 through 160. Each row represents an apparent signature from one through 4. (An apparent signature is a simulation object’s absolute signature after being modified by factors such as terrain and distance. For details, please see API documentation.)


                  image

                  Figure 71-1. Detection table displayed in a spreadsheet

                  The detection level is determined by finding the intersection of the apparent signature and the detection interval. For example, if a simulation object with an apparent signa- ture of 3 has been detected for 40 seconds, its detection certainty level is 4 (full knowl- edge).

                  The apparent signature is the ratio of the sensor signature given for the simulation object (in kilometers) to the actual range. So if the apparent signature = 1, the detection interval shows the increase in combat ID level over time when the target is at the range given by the sensor signature. If the apparent signature is 2, the detection interval shows the detection progression at 1/2 that range, and so on.

                  The numbers in the table represent the certainty levels as follows:

                  • 1 – Detected.

                  • 2 – Classified.

                  • 3 – Identified.

                  • 4 – Full Knowledge.

              For details about CID detection levels, please see “Detecting Targets,” on page 9-13.


              image

            2. Configuring Weapon Systems and Munition Damage

    This chapter describes configuration files for weapon systems in EntityLevel scenarios. Introduction to Entity-Level Weapon Systems 72-3

    Configuring Direct Fire Ballistic Weapons 72-4

    Sensing Targets 72-6

    Ammo Select Tables 72-8

    Hit Probability Tables 72-9

    Damage Probability Tables 72-10

    Configuring Missile Systems 72-11

    Missile Launcher 72-11

    Missile Projectile 72-12

    Laser Guided Missile Launcher 72-13

    Laser Guided Missile Projectile 72-13

    Configuring Indirect Fire Weapons 72-14

    Configuring Fixed Weapons 72-16

    Configuring Bomb Bay Weapon Systems 72-17

    Calculating Damage from Munitions 72-17

    Configuring Damage-by-Power 72-18

    Configuring the Power of a Detonation 72-19

    The Damage File for Damage-By-Power 72-21

    Adding a New Power Type 72-23

    Configuring Damage-by-Ammo-Type 72-25

    Configuring Damage for Damage-by-Ammo-Type 72-26

    Configuring Damage for Dynamic Terrain 72-28

    Standard Terrain Damage 72-28

    image

    Configuring Weapon Systems and Munition Damage

    High Fidelity Terrain Damage 72-29

    Direct Fire Configuration Examples 72-30

    Direct Fire Weapon Damage-By-Power Example 72-31

    Direct Fire Weapon Damage-by-Ammo-Type Example 72-36

    Configuring Weapon Systems and Munition Damage — Introduction to Entity-Level Weapon

    Systems

      1. Introduction to Entity-Level Weapon Systems

        Simulation objects in entity-level scenarios have many weapon systems. They all fall into one of the following types:

      2. Configuring Direct Fire Ballistic Weapons

        Entities that have direct fire weapons can fire in response to a fire target task and they can detect targets through their sensors and automatically fire at the targets. Entities have to be able to:

        • Know what targets they can fire at.

        • Detect the targets.

        • Determine the ammunition to use.

        • Acquire the target and fire at it.

          If you want to create a completely new type of weapon system, you must write code for the sensors, controllers, and actuators that it requires. However, if you need a system that is similar to an existing system, you can often create the new system by copying and modifying the configuration files of the existing system. To do so, you must under- stand the relationships between the different configuration files to allow you to:

        • Configure a weapon system.

        • Specify the simulation object types that can use the system.

        • Specify the simulation object types that can be damaged by the system.

        • Specify the amount of damage a simulation object receives from a munition. The files that manage these relationships are:

        • The weapon system. Defines the system, the simulation object types that it can target, and the simulation object types that can use it.

        • The ammo select file. Specifies the type of munition to use for each type of simula- tion object that a weapon can fire at.

        • The damage system. Specifies the types of munitions that a simulation object is vulnerable to and the damage file to use to determine the probability of damage.

        • The damage file. Specifies the probability that a simulation object will sustain damage and the type of damage it will sustain when hit by a particular munition in a particular location.


          • The hit file. Specifies the probability that a ballistic gun will hit a target at different distances. The hit file is not used for projectile weapons and indirect fire.

    For detailed examples of how to configure a direct fire weapon, please see “Direct Fire Weapon Damage-By-Power Example,” on page 72-31 and “Direct Fire Weapon Damage-by-Ammo-Type Example,” on page 72-36.

    The weapon does the following:

    1. Acquires the target.

    2. Selects the ammunition for the target using the ammo select file.

    3. Checks that it has that resource.

    4. Determines if it hits target.

    5. Sends a fire interaction.

    6. After a delay based on distance and muzzle speed, it sends a detonation interaction.


        1. Sensing Targets

          Simulation objects that have direct fire weapons detect targets through their sensors and automatically fire at the targets. Sensor systems can specify what types of targets to detect (using the detection-types parameter). The weapon systems can also tell the sensors what they want to target.

          Each weapon system has an associated weapon interface. The targeting-control parameter takes a list of desired target types and creates a target selection criteria object, which is then set in the weapon interface. The following code shows the targeting control for handheld-AK47.sysdef file. It also shows the ammo select file.

          (main-gun-control

          (component-descriptor-type "ballistic-gun-ctlr-descriptor") (component-type "ballistic-gun-controller")

          ...

          (ammo-select-table-file

          (filename "$(ammoselect-dir)\AKA762.asl")

          )

          (rounds-per-trigger-pull 5) (targeting-control

          (target-priorities (entity-priority

          (entity-type 3 1 -1 1 -1 -1 -1)

          (priority 1)

          )

          (entity-priority

          (entity-type 3 -1 -1 -1 -1 -1 -1)

          (priority 2)

          )

          )

          ...

          )

          The platform file for the entity uses its target selection controller to iterate through each weapon interface to create a list of object types to detect, which it outputs on its object- types-to-detect port.

          Each sensor on the entity connects to this port to know what types of objects to detect (Figure 72-1).


          image

          Weapon system


          ballistic-gun-controller

          targeting-control

          ballistic-gun-controller

          targeting-control


          Simulation Object


          target-selection-controller (from OPE file)

          object-types-to-detect


          Sensor System

          Sensor System

          Sensor System

          Sensor System


          Figure 72-1. Direct fire sensor input

          The simulation object gathers the detected objects from all the sensors and stores it in the entity’s state repository. (A state repository is a read-write repository of information that is available to all entity components.) The target selection controller selects a target for the weapon.


        2. Ammo Select Tables

          The ballistic gun controller descriptor refers to an ammo select table file, which contains the ammo select table for that controller. Each entry in this file specifies a target type (using the best match method) and a prioritized list of ammunition that should be used for that type of target (highest priority listed first). (The best match method is described in “The Best Match Method,” on page 69-7.) The name of the entry is not used, and so may be something descriptive for readability. Each entry has the following fields:

          • target-type – a 7-digit entity type enumeration, which can use -1s to denote wild- cards.

          • ammo – list of ammunition entries. The names of the ammunition entries are assumed to be the resource names. If the resource name is found in the Object Resource Manager, the amount of the ammunition is decremented appropriately, and is not used if the resource amount is 0. In this case, the next ammunition entry (if any) in the ammunition list is used. Each ammunition entry has the following fields:

            • munition-type – 7 digit object type enumeration. This is the object type that is used in the fire and detonation interactions created, and should NOT contain

              -1s.

            • tracer-type – 7 digit object type enumeration. This parameter is optional. Use it if you want a weapon to support tracer rounds.

            • warhead – VR-Link warhead enumeration value to use in fire and detonation interactions for this munition.

              The following is an example of an Ammo Select Table (M16.asl):

              (ammo-select-table

              (lifeform ;; matches any lifeform (target-type 3 -1 -1 -1 -1 -1 -1) (ammo

              (M16A2-556mm ;; these names need to match resource names (munition-type 2 8 225 2 1 1 0)

              (tracer-type 2 8 225 2 1 2 0)

              (warhead 0)

              )

              )

              )

              (civilian-vehicle ; "technical" (target-type 1 1 -1 27 -1 -1 -1) (ammo

              (M16A2-556mm ;; these names need to match resource names (munition-type 2 8 225 2 1 1 0)

              (tracer-type 2 8 225 2 1 2 0)

              (warhead 0)

              )

              )

              )

              )


        3. Hit Probability Tables

          A weapon system definition file specifies a hit probability file. This file contains a hit probability table that is used by the system’s actuator to determine whether or not it hits a target that it fires upon. A hit probability table has one or more entity-range entries. The name of the entity-range entry is not used, and can be something descriptive. An entity-range entry has the form:

          • entity-type – 7 digit entity type enumeration, which may use -1s as wildcards.

          • range-determinant – a range determinant can be either a list of probability-range entries with the name “range-list”, or a probability-coefficient list with the name “coefficients”.

          • range-list – a list of probability-range entries. A probability-range entry has a name, “range”, a range value (in meters) and a list of probability entries. The entry applies to targets in the range from the last entry to the current one (or from 0.0 in the case of the first entry). Each probability entry has a name that the table user uses to find the probability value it is interested in and the value itself (a real number between

            0.0 and 1.0.) The ballistic gun looks for the probability entry with the name “prob- ability”.


            image

            i

            i

            • For ranges that are greater than the last specified range, the probability is zero.

            • The range for missiles is the range from the missile to the target, not from the entity that fired the missile.


            image


          • coefficients – a coefficient probability list is a list of coefficient probability entries. Each entry has a probability name and the coefficients of a standard polynomial that can be used with a given range to determine the specified probability. The order of the polynomial is determined by the number of coefficients provided. For example, an entry of:

            (probability -5.00000E-008 -300000E-012 1.0000)

            indicates that the formula to use for a given range r would be:

            (-5.00000E-008 * r2) + (-300000E-012 * r) + 1.0

            Values calculated will be constrained to be between 0.0 and 1.0. Zero values are factored out, for example:

            (probability -5.00000E-008 0.0000 1.0000)

            indicates that the formula to use for a given range r would be:

            (- 5.00000E-008 * r2) + (0.0 * r) + 1.0


            The following is an example of the M1A2MainGun.hit hit probability table:

            (hit-probability-table (entity-range

            (entity-type 1 1 -1 -1 -1 -1 -1) (range-determinant

            (range-list

            (range 1000.000000

            (probability 0.90000)

            )

            (range 2000.000000

            (probability 0.8000)

            )

            (range 3000.000000

            (probability 0.75000)

            )

            (range 4000.000000

            (probability 0.70000)

            )

            )

            )

            )

            )


        4. Damage Probability Tables

    The damage actuator uses damage probability tables specified by its component descriptor to determine direct and indirect fire damage. The damage probability table has a list of surface entries, which provide a sub-table for each surface upon which a round might detonate. The name of the surface entry is the surface name used in the damage model.

    For the damage-by-power damage system, VR-Forces has damage probability tables for each power type. For more information, please see “Configuring the Damage File for Damage-By-Power,” on page 72-22.

    For the damage-by-ammo-type damage system, VR-Forces has damage probability tables for direct fire and collateral damage. A munition type does not need to have both types of probability table if one of the types is not appropriate. For example, an M16 does not have a collateral damage file. Conversely, an artillery shell does not have a direct fire probability table. For more information, please see “Configuring Damage for Damage-by-Ammo-Type,” on page 72-26.


      1. Configuring Missile Systems

        Missiles are launched by an object’s missile launcher system, which creates a missile entity. The missile flies itself and detonates based on the type of missile, as follows:

        • Direct flight. Missiles fly directly to a target. Accuracy is controlled by their maneu- verability parameters.

        • Laser guided. Missiles follow a laser designator to the target. If the laser is blocked or disrupted, the missile goes to the last known location of the target.

        • Route following. Some missiles, such as cruise missiles, can follow a route to a target and detonate either at the target or at a proximity to the target.


    image

    i

    i

    The range for missiles is the range from the detonation location to the target, not from the entity that fired the missile.


    image


        1. Missile Launcher

          The missile launcher for direct flight missiles works as follows:

          1. The target selection controller chooses the best target for the weapon system and passes it to the weapon through the weapon’s weapon-interface.

          2. The weapon system’s controller passes the target type to its ammo select table to find the right resource for that target type.

          3. The missile resource is returned and the system loads the missile to fire.

          4. The entity tries to acquire the target. It sends the desired rotation angle and eleva- tion to acquire the target to the rotating mount actuator and elevation mount actu- ator.

          5. Actuators move according to their slew rate speeds and send how far they went in a tick back to the weapon launcher so it can recalculate the remaining amount. It also publishes the articulated part numbers along with amount of rotation/elevation to the network.

          6. When the feedback has us reach our max angle off boresight, we can fire on the target. The missile object is created.

          7. Firing state is sent to the launcher actuator.

          8. The launcher actuator sends a fire interaction.

            Configuring Weapon Systems and Munition Damage — Configuring Missile Systems

            image


            Parameters in the missile launchers system definition file affect whether or not it fires. The following code is from ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/weapons/fixed-marverick-missile-launcher.sysdef:

            (controllers

            (missile-launcher-control

            ...

            (max-vehicle-speed-to-fire 500.000000)

            (max-azimuth-angle-off-boresight 1.570000)

            (max-elevation-angle-off-boresight 1.570000) (preload-weapon True)

            (load-ammo-time 1.000000)

            (unload-ammo-time 0.000000)

            ...

            )

            )


        2. Missile Projectile

          When the missile is created, it flies as follows:

          1. Using the missile’s movement parameters, the missile controller (track-entity if the target is an entity, or target-point if the target is a location) determines the values to be sent to the missile-maneuver actuator.

          2. The missile-maneuver actuator calculates the new position, velocity, acceleration, and orientation of the missile.

          3. The missile-collision actuator then checks to see if the missile is going to collide with the terrain or an entity. If so it sends out a detonation interaction.

            Missile parameters affect how it detonates. The following code is from ./data/simula- tionModelSets/EntityLevel/vrfSim/systems/weapons/missile-warhead.sysdef:

            (actuators (warhead

            ...

            (detonate-on-ground-impact True) (detonate-on-water-impact True) (detonate-on-entity-impact True) (allow-direct-hit True)

            ...

            )

            )


        3. Laser Guided Missile Launcher

          The missile launcher for laser guided missiles works as follows:

          1. The target selection controller chooses the best target for the weapon system and passes it to the weapon through the weapon’s weapon-interface.

          2. The weapon system’s launcher controller tells the lasing controller the targets.

          3. The lasing controller looks for an actively lased target that matches the lasing code. If there are no lased targets, it checks to see if it can autonomously lase. If it can, it starts to lase the target.

          4. Once the launcher controller has a lased target, it tells the movement system to rotate to the target.

          5. The launcher controller checks for when the entity has rotated to line up with target, within the fire cone defined for it. It creates the missile object and fire inter- action.


        4. Laser Guided Missile Projectile

          Once it is created, a laser-guided missile flies as follows:

          1. Using the missile’s movement parameters, the missile controller determines the values to be sent to the missile-maneuver actuator.

          2. The missile-maneuver actuator calculates the new position, velocity, acceleration, and orientation of the missile.

          3. The missile-collision actuator then checks if the missile is going to collide with terrain or an entity. If so it sends out a detonation interaction.

    Configuring Weapon Systems and Munition Damage — Configuring Indirect Fire Weapons

    image

      1. Configuring Indirect Fire Weapons

        Indirect fire weapon systems use the indirect-fire-weapon-controller. Indirect fire weapons fire in response to an indirect fire task, such as Fire-for-Effect or throw grenade. They do not fire on their own, like many direct fire weapons do.

        When a simulation object receives an indirect fire task, its indirect-fire-controller queues the task and checks for availability of an indirect fire weapon. It continues to check until a weapon becomes available. Then it sends the fire task to the weapon through the indirect weapon interface. If a task requires multiple weapons, the indirect- fire-controller continues this process until the task is complete. (The indirect-fire- controller and indirect weapon interface are analogous to the target-select-controller and weapon interface described for direct fire weapons.)

        When an indirect-fire-weapon-controller gets a task, it reads the fire mission from the indirect weapon interface. The indirect fire weapon controller tries to align the turret and load the munition. When the weapon is ready to fire, it passes the information to its indirect-fire-actuator.

        The munition is specified as part of the task. The indirect-fire-actuator creates the desired munition and sends out the fire interaction.

        Figure 72-2 illustrates this process.


        image

        Simulation Object

        indirect-fire-controller (from OPE file)


        Weapon system


        indirect-fire-weapon-controller

        indirect-fire-weapon-controller


        indirect-fire-actuator

        indirect-fire-actuator


        munition

        fire interaction

        munition

        fire interaction


        Figure 72-2. Indirect fire

        Configuring Weapon Systems and Munition Damage — Configuring Indirect Fire Weapons

        image


        image

        i

        i

        Do not confuse the indirect-fire-controller and the indirect-fire-weapon- controller. The indirect-fire-controller is on the simulation object that has the weapon system (it is in the platform OPE file). The indirect-fire-weapon- controller is in the indirect fire weapon system. The controllers are illustrated in Figure 72-2.


        image


        Examples of indirect fire weapons include the M284-155mm cannon (./data/simula- tionModelSets/EntityLevel/vrfSim/systems/weapons/M284-155mm-cannon.sysdef), the M252-81mm mortar (M252-81mm-mortar.sysdef), and MK45 naval gun (./data/simu- lationModelSets/EntityLevel/vrfSim/systems/weapons/MK45NavalGun.sysdef). Also, although hand grenades would not normally be thought of as indirect fire weapons, the hand grenade tasks call the fire for effect tasks. Therefore, they use the same controllers and actuators as indirect fire weapons.

        The munitions used by the indirect fire weapon systems are configured with explosive power in detonationParams.mtl. Therefore simulation objects that are susceptible to explosive power can be damaged by them. Their damage system definition files will point to the appropriate damage table files to assess damage from these munitions.

        As with other weapon systems, the system definition files for indirect fire weapons have parameters that control when they can be used an how effective they are. For example, they have minimum and maximum ranges, as shown in this snippet from the cannon- controller in M284-155mm-cannon.sysdef:

        (load-ammo-time 15.000000)

        (unload-ammo-time 5.000000) (default-ammo-list

        (m107 "M107-155mm")

        )

        (num-rounds-per-mission 5)

        (min-range 2000.000000)

        (max-range-list 5000.000000 10000.000000 15000.000000 20000.000000

        25000.000000 30000.000000)

        (range-name "M284-15mm Cannon")

        The following snippet is from the M284-cannon actuator in the same system definition file:

        (projectile-start-speed 0.000000)

        (muzzle-offset 6.090000 0.000000 0.000000)

        (probable-error-in-range 15.000000)

        (probable-error-in-displacement 4.000000)

        (probable-error-in-burst-height 5.000000) (simulate-munition True)

        Configuring Weapon Systems and Munition Damage — Configuring Fixed Weapons

        image

      2. Configuring Fixed Weapons

        Fixed munitions, such as mines and IEDs can be triggered in the following ways:

      3. Configuring Bomb Bay Weapon Systems

        The bomb-bay weapon system releases bombs in response to Release Bomb tasks. Bombs can drop directly onto targets or be laser guided. Once a bomb is released, it uses the ./data/simulationModelSets/EntityLevel/vrfSim/systems/movement/smart-bomb- dynamics.sysdef movement system to control movement. It has a warhead actuator that is similar to the warhead actuator in missiles. Its ability to navigate toward and hit its target is controlled by parameters that you can set in the Simulation Object Editor. For details, please see “Release Bomb Tasks,” on page 28-18.


      4. Calculating Damage from Munitions

        VR-Forces has the following ways to calculate damage:

      5. Configuring Damage-by-Power

        In the damage-by-power method of calculating damage, each munition has a detonation-power-entry block in ./data/simulationModelSets/base/detonation- Params.mtl. The following is the entry for the 7.62 mm bullet:

        (detonation-power-entry (munition

        ;; 7.62 mm

        (munition-type 2 8 222 2 2 -1 -1)

        (warhead -1)

        (guidance-mode 0)

        )

        (power-list (kinetic

        (direct 2.24) ;; Kilojoules

        )

        )

        )

        The munition block identifies the munition type using the DIS/RPR FOM object enumeration. (The default configuration does not use the warhead or guidance-mode parameters.)

        The power-list block is a list of domains and the configuration for a determinant that produces a power value based on an input range. In this example, the 7.62 mm shell has power in the kinetic domain.

        The default configurations support the following domains:

        • Explosive. Munitions that affect simulation objects within some range of the deto- nation. Explosive munitions represent power in kiloPascals (kPa) of incident pres- sure.

        • Kinetic. Munitions that directly strike a simulation object. Kinetic munitions represent power in kilojoules (kJ) of energy.

        • Armor-piercing. Munitions that strike an armored object and penetrate it. Armor piercing munitions represent power in millimeters of penetration.

        • Fragmentation. Explosives that cause damage by fragmenting, such as grenades.


    image

    i

    i

    You can add other domains without writing code. For details, please see “Adding a New Power Type,” on page 72-23.


    image


    The power values used in the default configuration are based on publicly available information about the power of the various types of munitions and the values used try to be consistent in their relative power.


        1. Configuring the Power of a Detonation

          To determine the power of a detonation at a specific location a power determinant must be defined. The determinant maps a range value to a power value. Range can have different possible meanings, depending on how the range-from parameter is defined for the determinant. If range-from is undefined, impact-point is assumed unless the determinant does not support this setting.

        2. The Damage File for Damage-By-Power

          Entity damage is configured through the system definition files and the damage files they reference. A system definition file configures power in the damage-by- munition-power block.

          The system definition files provided with VR-Forces have a damage-model block. However none of the files provided use this block. It is available for customers who want to configure munitions using the damage-by-ammo-type method. It also enables backwards compatibility with old SMSs. For information about using the damage- model block, please see “Configuring Damage-by-Ammo-Type,” on page 72-25.


          Configuring Damage-by-Power in a System Definition File

          A system definition file can define any number of damage-by-power-entry items, each for a different power-type. This is the damage domain of the power. To add a new type of power, add new settings in detonationParams.mtl and in the system definition files for simulation objects that need to be damaged by this effect.

          Each damage-by-power-entry specifies a damage file that defines how a power value maps to a damage probability. (Damage files are in ./data/simulationModelSets/Enti- tyLevel/vrfSim/damage.) The comments in the damage file indicate the unit of measure- ment for power.

          The following example is from ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/damage/ground-heavy-armor.sysdef:

          (damage-by-munition-power (damage-by-power-entry

          (power-type "explosive") (damage-file

          (filename "$(damage-dir)\heavy-armor-explosive.dmg")

          )

          )

          (damage-by-power-entry (power-type "kinetic") (damage-file

          (filename "$(damage-dir)\heavy-armor-kinetic.dmg")

          )

          )

          (damage-by-power-entry

          (power-type "armor-piercing") (damage-file

          (filename "$(damage-dir)\heavy-armor-armor-piercing.dmg")

          )


          )

          )

          (damage-model )

          It shows that simulation objects that use the ground-heavy-armor.sysdef system defintion file can be damaged by explosive, kinetic, and armor piercing power.


          Configuring the Damage File for Damage-By-Power

          Damage files configure damage based on the side of the bounding volume being affected. The damage actuator delivered with VR-Forces uses surfaces of front, rear, left-side, right-side, bottom, and top (other components could model the entity’s geom- etry differently, and therefore use different surface strings). A surface entry has a list of angle-of-incidence entries. An angle-of-incidence entry has an angle (in radians).

          The determinant block specifies the damage. The determinant can be a step- function or a list of coefficients. Each determinant can specify probabilities for cata- strophic-kill, mobility-kill, firepower-kill or some combination of them.

          The ground-heavy-armor.sysdef file has a parameter called round-down that indicates what probabilities should be used when the input power value is between two steps. For power we want to round down to the next lower power (and lesser probability). There- fore round-down is set to 1 (true) for all damage files. If this parameter is not specified, the step function rounds up.

          The following code, which uses the step-function determinant, is from

          ./data/simulationModelSets/EntityLevel/vrfSim/damage/heavy-armor-explosive.dmg:

          (damage-table (front

          (angle-of-incidence (angle 1.570800) (determinant

          (step-function (round-down 1)

          (power 7.5

          (catastrophic-kill 0.1)

          )

          (power 12.5

          (catastrophic-kill 0.5)

          )

          (power 20.0

          (catastrophic-kill 0.6)

          )

          (power 45.0

          (catastrophic-kill 0.75)

          )

          (power 70.0

          (catastrophic-kill 0.99)

          )

          )

          )

          )

          )

          ...

          )


          The following code, which uses the coefficients determinant, is from ./data/simu- lationModelSets/EntityLevel/vrfSim/damage/missile-explosive.dmg:

          (damage-table

          ...

          (left-side

          (angle-of-incidence (angle 1.5708) (determinant

          (coefficients

          (catastrophic-kill 0.02 -0.4)

          (firepower-kill 0.022 -0.44)

          (mobility-kill 0.025 -0.5)

          )

          )

          )

          )

          ...

          )


        3. Adding a New Power Type

    To add a new type of power, you add it to the relevant munitions in detonation- Params.mtl and then add it to the appropriate damage system. For example, suppose you want to model the effects of the heat generated by a munition. You could add thermal power. For the sake of this example, suppose that an 85mm HEAT round has thermal power. To add thermal power, you would have to do the following:

    1. Add the new power to the detonation-power-entry, as follows:

      (detonation-power-entry (munition

      ;; 85 mm HEAT

      (munition-type 2 2 222 2 8 1 -1)

      (warhead -1)

      (guidance-mode 0)

      )

      (power-list (explosive

      (range-from "impact-point") (range-list

      (range 3.5

      (power 70.0)

      )

      ...

      )

      )

      (kinetic

      (range-from "shooter-to-impact")

      (range-coefficients -2.6600E-004 0.0000 5319.0)

      )

      (armor-piercing

      (range-from "shooter-to-impact")

      (range-coefficients -9.0000E-006 0.0000 180.0)

      )

      (thermal

      (range-from "impact-point") (range-list


      (range 3.5

      (power 70.0)

      )

      ...

      )

      )

      )

      )

      You would have to determine the unit of heat that you wanted to use to measure its effect and come up with realistic power levels at different distances.

    2. In the damage systems for the simulation objects that can be affected by thermal power, add a damage-by-power entry. Suppose that you want lifeforms to be damaged by thermal power. You would update the lifeform-default.sysdef file as follows:

      (damage-by-munition-power (damage-by-power-entry

      (power-type "explosive") (damage-file

      (filename "$(damage-dir)\lifeform-explosive.dmg")

      )

      )

      (damage-by-power-entry (power-type "kinetic") (damage-file

      (filename "$(damage-dir)\lifeform-kinetic.dmg")

      )

      )

      (damage-by-power-entry (power-type "thermal") (damage-file

      (filename "$(damage-dir)\lifeform-thermal.dmg")

      )

      )

      )

    3. Create a damage file called lifeform-thermal.dmg. Configure it similarly to other damage files.


    72.9. Configuring Damage-by-Ammo-Type

    Damage-by-ammo-type is the damage configuration approach used by VR-Forces in release 4.4.2 and earlier. It is no longer the default approach. However, it is still supported both for backwards compatibility and for those cases where you want to configure a specific munition to affect a specific entity type.

    To configure damage-by-ammo-type, you add an ammo-entry to the damage- model block of the damage system system definition file (.sysdef) for each type of ammunition that you want a simulation object using that system definition to be vulnerable to. Then, you create a damage table (.dmg) for the type of damage that you can take.

    The following code is from vrforces4.4.2/data/simulationModelSets/Enti- tyLevel/vrfSim/systems/damage/lifeform-default.sysdef.

    (damage-model (ammo-entry

    (ammo

    ;;Ballistic anti-air munitions-- 20-30mm HE cannon (munition-type 2 1 -1 2 -1 -1 -1)

    (warhead -1)

    (guidance-mode 0)

    )

    (direct-damage-file

    (filename "$(damage-dir)\light-armor-vs-explosive-round.dmg

    )

    (collateral-damage-file

    (filename "$(damage-dir)\collateral-gnd-PG7.dmg")

    )

    )

    (ammo-entry (ammo

    (munition-type 2 2 222 1 8 -1 -1)

    (warhead -1)

    (guidance-mode 0)

    )

    (direct-damage-file (filename "")

    )

    (collateral-damage-file

    (filename "$(damage-dir)\gnd-TOW.dmg")

    )

    )

    ...

    )

    These entries specify two munition types that lifeforms are vulnerable to (anti-air munitions and TOW missiles). In the case of ballistic anti-air munitions, they can take collateral damage and direct damage. In the case of TOW missiles they can take collat- eral damage.

    Configuring Weapon Systems and Munition Damage — Configuring Damage-by-Ammo-Type

    image

    72.9.1. Configuring Damage for Damage-by-Ammo-Type

    As in damage-by-power, damage files for damage-by-ammo-type configure damage based on the side of the bounding volume being affected. The damage actuator deliv- ered with VR-Forces uses surfaces of front, rear, left-side, right-side, bottom, and top (other components could model the entity’s geometry differently, and therefore use different surface strings). A surface entry has a list of angle-of-incidence entries. An angle-of-incidence entry has an angle (in radians).

    A surface entry has a range-determinant. The entry is intended for use with angles of inci- dence that go from the previous entry’s specified angle to the current one (or in the case of the first entry, from 0.) The range determinant is exactly the same as the range deter- minant described in “Hit Probability Tables,” on page 72-9.

    The damage actuator provided by MAK looks for a probability entry with the name

    catastrophic-kill, mobility-kill, or firepower-kill.

    The following code is a portion of the damage table from vrforces4.4.2/data/simulation- ModelSets/EntityLevel/vrfSim/damage/light-armor-vs-explosive-round.dmg.

    (damage-table (front

    (angle-of-incidence

    (angle 0.5236) ;; 30 degrees (range-determinant

    (coefficients

    (catastrophic-kill -5.0000E-008 0.0000 1.0000)

    )

    )

    )

    (angle-of-incidence

    (angle 1.0472) ;; 60 degrees (range-determinant

    (coefficients

    (catastrophic-kill -5.0000E-008 0.0000 1.0000)

    )

    )


    ...

    )

    ...

    )


    The following code is a portion of the damage table from vrforces4.4.2/data/simulation- ModelSets/EntityLevel/vrfSim/damage/collateral-gnd-PG7.dmg.

    (damage-table (front

    (angle-of-incidence

    (angle 0.5236) ;; 30 degrees (range-determinant

    (range-list (range 1.000000

    (catastrophic-kill 0.900000)

    )

    (range 2.000000

    (catastrophic-kill 0.750000)

    )

    (range 5.000000

    (catastrophic-kill 0.600000)

    )

    (range 10.000000

    (catastrophic-kill 0.450000)

    )

    (range 15.000000

    (catastrophic-kill 0.050000)

    )

    )

    )

    ...

    )

    ...

    )

    Configuring Weapon Systems and Munition Damage — Configuring Damage for Dynamic Ter- rain

      1. Configuring Damage for Dynamic Terrain

        Dynamic terrain damage is configured using the damage-by-power approach. It is configured in ./data/simulationModelSets/base/vrfSim/systems/other/dynamic-terrain.sysdef in the settings for the dynamic-terrain-munition-damage controller. Terrain can be damaged using standard terrain damage or high fidelity terrain damage.


        1. Standard Terrain Damage

          When you use standard terrain damage, the controller publishes a series of concentric damage areas of decreasing damage from the impact point. The type of terrain damage (that is, the switch in the terrain to be updated) is defined by standard-terrain-damage-type in dynamic-terrain.sysdef. The detonation power domain that causes this damage is defined by standard-power-type. The standard-terrain-damage-table block specifies the concentric areas. When a detonation is received, for each entry in this table a new area is created based on the range that produces the specified power. Then the switch in the terrain model is set to the specified damage setting.

          The following code is from ./data/simulationModel- Sets/base/vrfSim/systems/other/dynamic-terrain.sysdef:

          (standard-terrain-damage-table (damage-by-power-entry

          (power 7)

          (damage "1")

          )

          (damage-by-power-entry (power 15)

          (damage "2")

          )

          (damage-by-power-entry (power 60)

          (damage "3")

          )

          )

          This table generates three dynamic terrain areas. The smallest area is defined by the area on the terrain that experiences an explosive power of at least 60. It is switched to a value of “3”. The next larger area is the area that experiences power between 15 and 60. It is switched to a value of “2”. Finally the outer area is the area that experiences power between 7 and 15. It is switched to a value of “1”.

          Configuring Weapon Systems and Munition Damage — Configuring Damage for Dynamic Ter-

          rain

        2. High Fidelity Terrain Damage

          You can configure high fidelity damage areas along with the standard damage. To deter- mine where high fidelity damage areas should be created, VR-Forces queries the terrain to find any dynamic terrain features that match the given dynamic-terrain-type setting.

          This can be used to generate additional or more specific types of damage to select loca- tions in the terrain that support a higher fidelity of damage. Just as with standard damage, a power-type is specified that corresponds to the detonation power domain that is causing this damage. High fidelity terrain damage is configured in the high- fidelity-terrain-damage-table block. It has the same format as the standard-terrain-damage-table.

          The high fidelity damage lets you specify the damage-algorithm used. VR-Forces only supports the range-based algorithm, but you can develop your own algorithms in a plug-in. If you add additional damage algorithms, they might require configuration options that are not supported in the high-fidelity-damage-table provided by MAK. If necessary, you can specify additional parameters using the additional-algorithm- config parameter, which accepts a list of key/value string pairs.

          High fidelity damage can produce a secondary detonation. This can be specified by setting detonation-on-destroy to True and defining the detonation-munition parameter. The delay parameter defines a delay in seconds between when power was first experienced and when the damage should be done. This allows the secondary detonation to create a particle effect that can mask the underlying terrain switch.

          The following code is from ./data/simulationModel- Sets/base/vrfSim/systems/other/dynamic-terrain.sysdef:

          (high-fidelity-terrain-damage-table (entry

          (dynamic-terrain-type "damage_house") (power-type "explosive")

          (damage-algorithm "range-based") (delay 2.0)

          (detonate-on-destroy True) (detonation-munition 2 0 0 4 2 0 0) (terrain-damage-table

          (damage-by-power-entry

          (power 7) ;; explosive power is in kPa (damage "1")

          )

          (damage-by-power-entry (power 15)

          (damage "2")

          )

          (damage-by-power-entry (power 60)

          (damage "3")

          )

          )

          (additional-algorithm-config

          ;; Additional key/value pairs (string values) can be added here for

          ;; custom algorithm configuration

          ;; For example:

          ;; (my-custom-algorithm-config "config value string")


          )

          )

          )


      2. Direct Fire Configuration Examples

        This section has two examples of how to configure a direct fire weapon. The first uses the damage-by-power method. The second uses the damage-by-ammo-type method.


        1. Direct Fire Weapon Damage-By-Power Example

          This section describes the files that work together to define an M240 machine gun and allow it to fire on and damage entities. Figure 72-4 illustrates the relationships between the files. (The lines of code are not in context. They are the minimum needed to show the connections between the files.)


          image

          image

          M240-7_62mm-mach-gun.sysdef

          (entity-priority

          (entity-type 3 1 -1 -1 -1 -1 -1))) (NATO-7.62x51mm)

          image

          (hit-probability-file (filename $(hit-dir)\M2.hit))

          image

          image

          (allowed-state-repository-types "ground-vehicle-param" "rotary-wing- entity-param")


          image

          image

          image

          detonationParams.mtl (detonation-power-entry

          ;; 7.62 mm image

          image

          image

          (munition (munition-type 2 8 -1 2 2 -1 -1))) (power-list

          (kinetic (direct 2.24) ;; Kilojoules)))

          image


          image

          image

          M240.asl

          image

          image

          (target-type 3 -1 -1 -1 -1 -1 -1) (NATO-7.62x51mm

          (munition-type 2 8 225 2 2 5 0)

          image


          image

          image

          lifeform-default.sysdef

          image

          image

          (damage-by-power-entry (power-type "kinetic")

          (damage-file (filename "$(damage-dir)\lifeform-kinetic.dmg”))

          image


          image

          M2.hit

          image

          image

          (entity-type 3 -1 -1 -1 -1 -1 -1)


          lifeform-kinetic.dmg damage-table

          Lines indicate relationships between configuration file parameters and files.


          Figure 72-3. Anatomy of a weapon system using damage-by-power


          The Weapon System System Definition File

          The M240 machine gun is configured in ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/weapons/M240-7_62mm-mach-gun.sysdef. Most of the file speci- fies the various components of the system that make it work. We are interested in the lines that help it connect to other files.

          The meta-data section of a system definition file provides information the Simulation Object Editor needs to make the system available in the systems section.

          In the following code snippet, the allowed-state-repositories-types parameter specifies that ground vehicles and rotary-wing entities can use this system.

          (meta-data

          (system-name "M240 Machine Gun")

          (system-description "Vehicle mounted M240 7.62mm Machine Gun. Typical secondary gun on tanks such as the M1A2. Targets lifeforms and unarmored vehicles.")

          (allowed-state-repository-types "ground-vehicle-param" "rotary-wing- entity-param")

          (system-categories "weapon")

          The resources section specifies the type of ammunition this weapon uses.

          (resources

          (NATO-7.62x51mm

          ...

          )

          The targeting control section specifies the entity types that this system can fire at — humans and several types of ground vehicles. Note that wildcards are used for entity types.

          (targeting-control (target-priorities

          (entity-priority

          (entity-type 3 1 -1 1 1 -1 -1)

          (priority 2)

          )

          (entity-priority

          (entity-type 3 1 -1 -1 -1 -1 -1)

          (priority 2)

          )

          (entity-priority

          (entity-type 1 1 -1 7 -1 -1 -1); large trucks

          (priority 3)

          )

          ...

          )

          )


          Finally, a ballistic direct fire weapon system system definition file specifies a hit file for the munition it uses. The hit file specifies the probability that targets will get hit by the munition.

          (main-gun-joy

          (component-descriptor-type "ballistic-gun-descriptor")

          ...

          (velocity-affects-hit-chance False) (hit-probability-file

          (filename "$(hit-dir)\M2.hit")

          )

          (range-name $display-name (default "M240 MG")) (start-with-tracers true)

          )

          Although this section shows code snippets from the system definition file, we recom- mend that you edit systems in the OPD Editor.


          The Ammo Select File

          When an entity with an M240 machine gun detects a target, it must choose the correct ammunition for that target. This is specified in the ammo select file. The ammo select file for the M240 is ./data/simulationModelSets/EntityLevel/vrfSim/ammoselect\M240.asl.

          The file has entries like the following:

          (lifeform ;; matches any lifeform (target-type 3 -1 -1 -1 -1 -1 -1) (ammo

          (NATO-7.62x51mm ;; these names need to match resource names (munition-type 2 8 225 2 2 5 0)

          (tracer-type 2 8 225 2 2 4 0) ; Ball/tracer mix, 4:1

          (warhead 0)

          )

          )

          )

          There is an entry for each of the target types in M240-7_62mm-mach-gun.sysdef. If you specify a target type in a weapon system definition file and do not have a corresponding entry in an ammo select file, the weapon will not know what kind of ammunition to use for that target type and will not fire on it.

          For each target, it specifies the entity type for the munition and tracer bullet.


          image

          i

          i

          Weapon systems that fire autonomously, such as the main guns on tanks, machine guns, and missiles, need an ammo select file. Some weapons, such as artillery and naval guns, do not need an ammo select file because they only fire when tasked by users or in a plan, and the choice of munition is one of the task parameters.


          image


          The detonationParams.mtl File

          As noted in previous sections, the M240 gun uses a 7.62 mm munition. The detona- tionParams.mtl file specifies that a 7.62 mm munition has kinetic power.


          The Damage System System Definition File

          Each simulation object has a damage system. The M240 can target lifeforms. Most life- forms use the Default Armor damage system. It is configured in ./data/simulationModel- Sets/EntityLevel/vrfSim/systems/damage/lifeform-default.sysdef. This file uses the damage- by-power configuration. It specifies that a lifeform can be damaged by explosive power and kinetic power.

          (damage-by-munition-power (damage-by-power-entry

          (power-type "explosive") (damage-file

          (filename "$(damage-dir)\lifeform-explosive.dmg")

          )

          )

          (damage-by-power-entry (power-type "kinetic") (damage-file

          (filename "$(damage-dir)\lifeform-kinetic.dmg")

          )

          )

          )

          Since the M240 machine gun fires a munition that has kinetic power, if a lifeform is attacked by this munition, VR-Forces looks at the lifeform-kinetic.dmg damage file to calculate damage.


          The Hit File

          A hit file specifies the probability that a simulation object will be hit by a type of muni- tion at various distances. The hit file specified by the M240 system definition is M2.hit. It has an entry for each simulation object type that can be struck by this munition type. The following code snippet is the entry for human entities.

          (entity-range

          (entity-type 3 -1 -1 -1 -1 -1 -1) (range-determinant

          (range-list

          (range 10.000000

          (probability 1.00000)

          )

          (range 200.000000

          (probability 0.80000)

          )

          (range 500.000000

          (probability 0.4000)

          )

          (range 1000.0

          (probability 0.2)

          )

          (range 3600.000000

          (probability 0.100)

          )

          )

          )

          )

          For more information about hit files, please see “Hit Probability Tables,” on page 72-9.


          The Damage File

          Once a simulation object has been fired on, with an appropriate munition, for which it can take damage, and by which it can be hit, VR-Forces calculates the damage using the damage file specified in the damage system definition file. For the M240 machine gun, targeting a human entity, the damage file is lifeform-kinetic.dmg.

          Based on the side of the entity that is hit, the angle it is hit at, and the range of the munition, the damage file specifies the type of damage caused.

          For more information about damage files, please see “Damage Probability Tables,” on page 72-10.


        2. Direct Fire Weapon Damage-by-Ammo-Type Example

    This section describes the files that work together to define an M240 machine gun and allow it to fire on and damage entities using the damage-by-ammo-type method. Figure 72-4 illustrates the relationships between the files. (The lines of code are not in context. They are the minimum needed to show the connections between the files.)

    In the damage-by-ammo-type approach, the hit file, ammo select file, and weapon system file are the same as in the damage-by-power approach and will not be discussed in this section. The damage system system definition file is different, as is the damage file. The detonationParams.mtl file is not used.


    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    M240-7_62mm-mach-gun.sysdef


    (entity-priority

    (entity-type 3 1 -1 -1 -1 -1 -1)

    )

    (NATO-7.62x51mm

    $(hit-dir)\M2.hit

    (allowed-state-repository-types "ground- vehicle-param" "rotary-wing-entity-param")



    M240.asl

    (target-type 3 -1 -1 -1 -1 -1 -1) (NATO-7.62x51mm

    (munition-type 2 8 225 2 2 5 0)


    lifeform-default.sysdef

    (ammo

    (munition-type 2 8 -1 2 -1 -1 -1) (filename "$(damage-dir)\rifle.dmg")


    M2.hit

    (entity-type 3 -1 -1 -1 -1 -1 -1)


    rifle.dmg


    damage-table


    Lines indicate relationships between configuration file parameters.


    Figure 72-4. Anatomy of a weapon system using damage-by-ammo-type


    The Damage System System Definition File

    Each simulation object has a damage system. The M240 can target lifeforms. Most life- forms use the Default Armor damage system. For the damage-by-ammo-type approach, in VR-Forces 4.4.2 or earlier, it is configured in ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/damage/lifeform-default.sysdef. The damage system has a a damage-model block with an ammo-entry block for each type of ammunition that simulation objects that use the damage system are vulnerable to. The ammo entry can specify a damage file (.dmg) for direct hits and for collateral damage. The lifeform- default.sysdef includes the following ammo entry:

    (damage-model

    ...

    (ammo-entry (ammo

    munition-type 2 8 -1 2 -1 -1 -1)

    (warhead -1)

    (guidance-mode 0)

    )

    (direct-damage-file

    (filename "$(damage-dir)\rifle.dmg")

    )

    (collateral-damage-file (filename "")

    )

    )

    )

    The munition-type parameter uses wildcard values that match the munition type sent by the M240 machine gun (2 8 225 2 2 5 0). This means that a human entity that uses the Default Armor damage file can be damaged by a bullet fired by an M240 machine gun.


    The Damage File

    Once a simulation object has been fired on, with an appropriate munition, for which it can take damage, and by which it can be hit, VR-Forces calculates the damage using the damage file specified in the damage system definition file. For the M240 machine gun, targeting a human entity, the damage file is rifle.dmg.

    Based on the side of the entity that is hit, the angle it is hit at, and the range of the munition, the damage file specifies the type of damage caused.

    For more information about damage files, please see “Damage Probability Tables,” on page 72-10.


    image

    73. Configuring Movement Systems


    This chapter describes configuration files that affect simulation object movement.

    Configuring Formations 73-2

    Formation Files 73-3

    Creating a User-Defined Formation 73-4

    Configuring Obstruction Avoidance 73-4

    Configuring Object Types 73-5

    Configuring Vector Feature Types 73-5

    Configuring Embarkation 73-6

    Configuring Movement Systems — Configuring Formations

    image

    image

      1. Configuring Formations



        image

        i

        i

        Although you can create and edit formation files by hand as described in this section, the recommended way to create and edit formations is to use the Simulation Object Editor.


        image


        The object parameter database lists the formations available to a unit in the formations element in its .entity file. Each formation is identified by its name and the path to the formation file, for example:

        <formations paramName="formation-list" autoLayout="0">

        <formation formationName="Line" formationFile= "@(formation-dir)/platoonLine.frm"/>

        <formation formationName="Column" formationFile= "@(formation-dir)/platoonColumn.frm"/>

        <formation formationName="Wedge" formationFile= "@(formation-dir)/platoonWedge.frm"/>

        <formation formationName="Vee" formationFile= "@(formation-dir)/platoonVee.frm"/>

        </formations>


        image

        1. Formation Files

          Configuring Movement Systems — Configuring Formations

          A formation file specifies the name of the formation and has an entry for each simula- tion object in the default formation definition. Each entry specifies a promotion-id, a leader-promotion-id, and a position-offset, where:

          • The promotion-id specifies the order in which simulation objects are promoted to unit leader if the leader is incapacitated.

          • The leader-promotion-id specifies the unit member from whom the entry’s position will be offset.

          • The position-offset specifies how many meters behind, to the right, and above the entry will follow its leader. The position-offset is specified in terms of the body coor- dinate system of its leader.

            The following is a portion of the formation file for a column formation:

            (column-formation (entry-0

            (promotion-id 0)

            (leader-promotion-id -1)

            (position-offset 0.000000 0.000000 0.000000)

            )

            (entry-1

            (promotion-id 1)

            (leader-promotion-id 0)

            (position-offset -25.000000 0.000000 0.000000)

            )

            (entry-2

            (promotion-id 2)

            (leader-promotion-id 1)

            (position-offset -25.000000 0.000000 0.000000)

            )

            (entry-3

            (promotion-id 3)

            (leader-promotion-id 2)

            (position-offset -25.000000 0.000000 0.000000)

            )

            )

            In a column, each simulation object follows the simulation object in front of it by 25 meters. Therefore, the leader-promotion-id for each entry is the promotion-id of the simula- tion object in front of it, and each entry has a position-offset of -25 meters.

            The number of entries in a formation file is finite. However, it is possible to place more simulation objects into a unit than there are entries in a formation file. If this happens, VR-Forces increments the promotion-id of the last entry in the formation file and assigns the new simulation object the same position-offset as the last entry in the formation file. For a simple formation like a column, this works well. If you are using a more complex formation, this mechanism might create unintended relationships among simulation objects.

            If you want to change the layout of the formations provided with VR-Forces, you can edit the formation files.

            Configuring Movement Systems — Configuring Obstruction Avoidance

            image

        2. Creating a User-Defined Formation

    You can create formations other than those provided by VR-Forces. It is recommended that you create formations in the Simulation Object Editor. If you use the Simulation Object Editor, you do not have to edit any formation files or .entity files by hand.

    To create a formation:

    1. Using one of the formation files supplied with VR-Forces as your template, place as many entries as you want in the formation file and specify their offsets.

    2. Save the new formation under a new name.

    3. Add an entry to the formation list block in the .entity file for each unit that you want to be able to use the formation. Be sure to use the same structure and naming conventions as the default entries. For example:

      <formations paramName="formation-list" autoLayout="0">

      <formation formationName="Line" formationFile="@( formation-dir)/DI-companyLine.frm"/>

      <formation formationName="Column" formationFile="@( formation-dir)/DI-companyColumn.frm.frm"/>

      <formation formationName="Wedge" formationFile="@( formation-dir)/DI-companyWedge.frm"/>

      <formation formationName="Vee" formationFile="@( formation-dir)/DI-companyVee.frm"/>

      </formations>

      We recommend that you configure your formations so that simulation objects follow the leader, rather than the next closest member of the formation (as is done in column formation.) This ensures that formations have the best chance of maintaining their formation as they maneuver.


        1. Configuring Obstruction Avoidance

          You can configure ground entities to avoid specific entity types, vector features, or both.


          image

          i

          i

          The more vector feature types and entity types specified for avoidance, the more memory and processing power required.


          image


          Obstruction avoidance is influenced by the stopping-distance-factor and lateral-clearance parameters. If entities display erratic behavior, try raising the values, lowering the speed of the entities, or both.

          Configuring Movement Systems — Configuring Obstruction Avoidance

          image

          1. Configuring Object Types

            To specify the types of objects that an entity type should avoid, add or remove the appropriate object type from the obstruction sensor entry in the movement system defi- nition file. For example, the following object types are configured for ground entities:

            (object-type

            (object-type 1 (18 -1 -1 2 -1 -1 -1)) ;; vrfObstacles object type

            (object-type 1 (1 -1 -1 -1 -1 -1 -1)) ;; DtPlatform entity kind

            (object-type 1 (3 -1 -1 -1 -1 -1 -1)) ;; DtLifeForm entity kind

            )


          2. Configuring Vector Feature Types

            Configuring avoidance of vector features relies on the attributes on the feature data as well as the named queries defined in ./appData/settings/featureconfig.txt. To configure specific feature data for obstruction avoidance, modify the feature-types-to-avoid type list in the obstruction sensor in the appropriate system definition file. The types in this file are named feature queries, and you can add as many as you need.

            Example of human.sysdef:

            (obstruction-sensor

            ...

            (feature-types-to-avoid (type "MAK_OBSTACLE")

            )

            )

            Example of air-cushion-default.sysdef. This entity specifically calls out building, infra- structure, and vegetation, instead of obstacle, because obstacle also includes waterway.

            (obstruction-sensor

            ...

            (feature-types-to-avoid (type "MAK_BUILDING")

            (type "MAK_INFRASTRUCTURE") (type "MAK_VEGETATION")

            )

            )

            Configuring Movement Systems — Configuring Embarkation

            image

        2. Configuring Embarkation

      Entities and units that are configured to allow entities to embark on them have an occu- pancy-director-controller component. Its parameters configure embarkation, as follows:

      The embarkation-slots parameter has one or more embarkation-slot-entry parameters that identify a location on the entity where an embarked entity can be placed. The embarka- tion-slot-entry parameters also specify the orientation of the embarked entity and the types of entities that can occupy the slot.

      The ingress-points and egress-points parameters each have one or more load-entry parame- ters. The load-entry parameters specify one or more load-entry-point parameters. If there is one load-entry-point, an embarked entity enters the parent entity at that point and is immediately placed in an available slot. If a load-entry has multiple load entry points, they specify the points in a route that the embarking entity follows to reach its slot.

      This configuration is for large parent entities, such as aircraft carriers, on which entities land and then taxi to a slot.

      You configure embarkation in the Simulation Object Editor. For details, please see “Configuring Embarkation,” on page 65-34.


      image

      1. Configuring Emitters and Radios


        This chapter describes configuration files for emitters and radios. For information about configuring the display of emitters, please see Chapter 84, Configuring Emitter Volumes.

        Configuring Emitters 74-2

        Configuring Radios 74-4

        Publishing Radio Transmitters 74-4

        Configuring Emitters and Radios — Configuring Emitters

        image

          1. Configuring Emitters

            All fixed-wing aircraft have emitters as part of their radar sensor. Emitters have search modes. Search modes have a list of beams. You can configure entities with emitters that have more than one beam. You can also configure multiple emitters. The basic radar sensor with an emitter and two search modes (./data/simulationModel- Sets/<model_set>/vrfSim/systems/sensors/active-radar-sensor.sysdef) is as follows:

            (active-radar-sensor-system (systems )

            (sensors

            (radar-sensor

            (component-descriptor-type "radar-signature-sensor-descriptor") (component-type "radar-signature-sensor")

            . . .

            (sensor-domain "radar")

            (sensor-offset $sensor-position) (sensor-positional-error 0.000000) (detection-level-determinator

            (determinator-type "signature-detection-level-determinator") (detection-level-to-set-hostility 3)

            (combat-identification-level-table-file

            (filename "$(detection-dir)\std-radar-detection-table.csv")

            )

            )

            (detection-period 0.000000) (publish-emitter-system True) (emitter-system

            (system-name-enum 5570)

            (system-function-enum 5) (radar-mode-list

            (search-mode (index 0)

            (radar-mode "Search") (beam-list

            (beam-0 (index 0)

            (type "track")

            (frequency 4999999488.000000)

            (frequency-range 10000.000000)

            (power 70.000000)

            (pulse-repetition-frequency 0.000000)

            (pulse-width 0.000000)

            (azimuth-center 0.000000)

            (azimuth-sweep 0.523599)

            (elevation-center 0.349066)

            (elevation-sweep 0.523599)

            (sweep-sync 0.000000)

            (beam-function-enum 1)

            (beam-param-index 0)

            )

            )

            )

            (track-mode (index 1)

            (radar-mode "Track") (beam-list

            (beam-0

            Configuring Emitters and Radios — Configuring Emitters

            image


            ...

            )

            )

            )

            )

            )

            )

            )

            To configure multiple emitters for an entity, add additional radar-sensor blocks. Each block must have a unique name. For example:

            (radar-sensor-1

            (component-descriptor-type "radar-signature-sensor-descriptor") (component-type "radar-signature-sensor")

            . . .

            (emitter-system

            ...

            )

            )

            )

            (radar-sensor-2

            (component-descriptor-type "radar-signature-sensor-descriptor") (component-type "radar-signature-sensor")

            . . .

            (emitter-system

            ...

            )

            )

            )

            To add multiple modes on an emitter, add additional mode blocks to the radar mode list. The names of radar modes (for example, track-mode and search-mode) and the value for the radar-mode parameter are arbitrary. You can name them whatever you want.

            To add multiple beams on a radar mode, add additional beam-list blocks and change the name of each block. For example:

            (search-mode (index 0)

            (radar-mode "Search") (beam-list

            (beam-0

            ...

            )

            (beam-1

            ...

            )

            )

            )

            Configuring Emitters and Radios — Configuring Radios

            image

          2. Configuring Radios

            All radios are DtVrfRadio classes or subclasses. The radio is responsible for managing incoming and outgoing radio messages on a single simulation object. Each radio is asso- ciated with a specific communication model, and uses this communication model to send and receive messages.

            Radios are configured in platform (OPE) files. The radios block in the OPE file lists all the radios on the simulation object and the parameters for each radio. Parameters include the type of radio descriptor and type of radio class, which are strings used to create the C++ classes from the factories. The comm-model-name parameter identifies which communication model a radio is associated with. Every radio must be associated with a communication model.

            A typical radio entry is as follows:

            (main-radio

            (radio-descriptor-type "radio-descriptor") (radio-type "default-radio")

            (comm-model-name "default-radio-model") (publish-transmitter True)

            (transmitter-params

            (radio-type 7 1 225 2 1 20)

            (initial-frequency 3000000.000000)

            (power 30.000000)

            )

            )


            1. Publishing Radio Transmitters

              The external communication model requires that any simulation objects sending or receiving messages though the communications effects server publish a DIS or HLA radio transmitter object. By default, the internal communication model does not publish radio transmitters.

              Publishing radio transmitters is controlled by two parameters:

              • The publish-transmitters parameter in ./data/simulationModel- Sets/<model_set>/commModelParams.mtl. By default, this parameter is False for the simple communication model and True for the external communication model.

              • The publish-transmitter parameter in an entity’s OPE file. This parameter is set to true for all object types.

        To publish radio transmitters, both of these parameters must be True. If you do not change the OPE files and set publish-transmitters to True, all simulation objects will publish radio transmitters. If you set publish-transmitters to True and do not want all simulation objects to publish radio transmitters, you can set publish-transmitter to False for the object types that you do not want to publish them.


        image

      2. Configuring Joystick and Keyboard Controls


    This chapter explains how to configure joysticks and the keyboard to control entity movement.

    Configuring Joysticks and Keyboard Control 75-2

    Creating a Joystick Configuration 75-4

    Mapping the Joystick Stick 75-6

    Mapping Joystick Buttons and Keyboard Keys 75-7

    Configuring “Switch Between” Options 75-10

    Using Multiple Joysticks 75-13

    Specifying a Favorite Joystick Configuration 75-14

      1. Configuring Joysticks and Keyboard Control

        You can control entity movement and weapon fire using a joystick, the keyboard, or both. You can attach multiple joysticks and can use a mix of joystick and keyboard control at the same time. You configure joystick and keyboard mappings on the Appli- cation Settings dialog box, Joystick Configuration page.

        The controls available for configuration on the Joystick Configuration page are taken from the joystick controllers in the movement, gun, and other system definitions. For example, the ground-tracked.sysdef file has the following entry:

        (joystick

        (component-descriptor-type "joy-controller-descriptor") (component-type "ground-move-joystick-controller")

        ...

        (joystick-controls (steering

        (function-name "steering") (function-group $automotive-driving)

        (description "Controls the steering of this entity") (min-value -1.0)

        (max-value 1.0)

        )

        (throttle

        (function-name "throttle") (function-group $automotive-driving)

        (description "Controls the throttle of this entity") (min-value 0.0)

        (max-value 1.0)

        )

        (brake

        (function-name "brake")

        (function-group $automotive-driving)

        (description "Controls the braking of this entity") (min-value 1.0)

        (max-value 1.0)

        )

        (change-gear

        (function-name "change-gear") (function-group $automotive-driving)

        (description "Puts the entity in forward, reverse or pivot gear") (min-value 0)

        (max-value 2)

        (cycle True) ;; Each click cycles from min to max

        )

        )

        )

        Based on this sysdef file, the Joystick Configuration page (Figure 75-1) has an Automo- tive Driving function with controls for brake, change-gear, steering, and throttle.


        The min-value and max-value parameters determine how the edit buttons on the Joystick Configuration page work, as follows:

        image

        • If min-value and max-value are both set to 1 (as in the brake control in the example system definition file), the control is a key mapping button ( ). You can set it to Yes or No.

        • If max-value is an integer greater than 1 (as in the change gear control in the example system definition file), the control is a key mapping button. You can configure keyboard buttons to increase or decrease the control by 1, or to set it to a specific value.

          image

        • If min-value does not equal max-value and max-value is less than or equal to 1 (as in the throttle control in the example system definition file), there is a joystick button ( ) and a key mapping button on the Joystick Configuration page. The keyboard button lets you specify a percentage increase or decrease of the control value. (For example, increase throttle by 10%.)


        1. Creating a Joystick Configuration

          A joystick configuration contains the joystick mappings and, optionally, keyboard mappings that you can use to control an entity. VR-Forces includes default configura- tions for a gamepad and a joystick.

          To create a joystick configuration:

          1. Create or open a scenario.

          2. Choose Settings Application. The Application Settings dialog box opens.

          3. Select the Joystick Configuration page (Figure 75-1).


            image

            Figure 75-1. Joystick Configuration page

            image

          4. Click the Add button ( ). The New Configuration dialog box opens.

          5. Type a name for the configuration.

          6. Click OK. The window redisplays to show the functions that this device can control (Figure 75-2).



            image

            Figure 75-2. Joystick configuration

          7. Edit the joystick and keyboard mappings as described in “Mapping the Joystick Stick,” on page 75-6 and “Mapping Joystick Buttons and Keyboard Keys,” on page 75-7.


        2. Mapping the Joystick Stick

          To control an entity with a joystick, you map the joystick controls to specific entity movement components and weapons.

          To map joystick controls:

          1. Create a joystick configuration, as described in “Creating a Joystick Configura- tion,” on page 75-4.

            image

          2. On the Joystick Configuration page (Figure 75-2), click the Joystick button ( ) for the function you want to map. A joystick configuration dialog box opens (Figure 75-3).


            image

            Figure 75-3. Joystick configuration dialog box

          3. In the Controller list, select the controller you want to configure.

          4. Configure each axis as follows:

            1. To let VR-Forces select the axis, select the Detect option and move the joystick in the axis you want to use for this control.

            2. To choose the axis, select the Select option and select an Axis from the list.

            3. Move the joystick in the axis you are configuring. If the Maximum/Minimum slider moves in the direction that you expect, you are finished. If the slider moves opposite to what you expect, select the Reverse Axis check box. It should now move as expected.

          5. Click OK.

          6. Repeat this process for each function you want to control with the joystick.


        3. Mapping Joystick Buttons and Keyboard Keys

          You can map joystick buttons and keyboard keys to entity movement control and weapon control. When entity control is enabled, the entity control key mappings over- ride any other key mappings, such as observer control mappings.

          To map joystick buttons and keyboard keys to entity control:

          1. Create a joystick configuration, as described in “Creating a Joystick Configura- tion,” on page 75-4.

            image

          2. On the Joystick Configuration page (Figure 75-2), click the Key Mapping button ( ) for the control you want to map. A configuration dialog box opens. It may call for a range of values (Figure 75-4), or just be a toggle (Figure 75-5).


            image

            Figure 75-4. Key mapping configuration dialog box


            image


            Figure 75-5. Key mapping configuration as toggle dialog box

          3. If the mapping requires a range, for each row in the dialog box, do the following:

            image

            1. Click the Key Mapping button ( ). The Choose Control Button/Key dialog box opens (Figure 75-5).

            2. Press the joystick button or keyboard key that you want to use to activate this control. It is displayed in the dialog box (Figure 75-6). (If a key binding is not available, the OK button does not become activated.)


              image image

              Key Joystick button

              Figure 75-6. Choose Control Button/Key dialog box with selection

            3. Click OK.

            4. In the Action column, select an option from the list.

            5. In the Value column, enter an appropriate value for the Action option.

            6. In the On Release column, select an option from the list. (This is what happens when you release the key.) A complete dialog box looks similar to Figure 75-7.



              image


              Figure 75-7. Key mapping configuration dialog box

          4. If the keyboard mapping is a toggle, The Choose Control Button/Key dialog box opens automatically. Do the following:

            1. Press the key or joystick button that you want to use.

            2. Click OK.

            3. In the Repeat column, select Yes or No. Yes means that the action repeats if you hold down the key. No means it happens one time for each key press.

          5. Click OK.

          6. Repeat this process for each function you want to configure.


        4. Configuring “Switch Between” Options

          Some entities may have multiple systems of a certain type, such as weapons. You might want to be able to control all similar systems with the same set of keys and joystick controls. VR-Forces lets you do this with switch groups. You can specify a key or button to press to switch between the different systems in a switch group. For example, you might press a button to switch between a tank’s main battle gun and a machine gun.

          The controls for which you can specify a switch between option are listed in the Switch Between section of the Joystick Configuration page. Specifying the key or button to use is described in “Mapping Joystick Buttons and Keyboard Keys,” on page 75-7. This section explains how to set up switch options.

          To set up a switch option, when you define a function group in a system definition file’s meta data, you use the syntax switch_option:system. The switch_option is a keyword. If an entity has multiple systems that use that keyword, you can switch between them using the switch between key or button. VR-Forces systems use the weapon keyword for switching between weapon systems. The following code, from 120mm-gun.sysdef shows how this works.

          The controllers specify two function groups for joystick control – $slew-group and

          $ballistic-gun-group. These groups specify four functions that the joystick can control – slew, elevation, fire, and change ammo:

          (weapon-120mm-gun (controllers

          (turret-joystick

          ...

          (joystick-controls (slew

          (function-name "slew") (function-group $slew-group)

          (description "Controls the slew of this weapon") (min-value -1.0)

          (max-value 1.0)

          )

          )

          )

          ...

          (main-gun-control-joy (joystick-controls

          (elevation

          (function-name "elevation")

          (function-group $ballistic-gun-group)

          (description "Controls the elevation of this weapon") (min-value -1.0)

          (max-value 1.0)

          )

          (fire

          (function-name "fire")

          (function-group $ballistic-gun-group) (description "Fires this weapon") (min-value 1.0)

          (max-value 1.0)

          )

          (change-ammo


          (function-name "change ammo") (function-group $ballistic-gun-group)

          (description "Changes the ammo of this weapon") (min-value 1.0)

          (max-value 1.0)

          )

          )

          The meta-data section of the sysdef file specifies a value for these groups. It is specified as the keyword weapon followed by the name of the system – weapon:120mm Ballistic Gun:

          (meta-data

          (system-name "120mm Gun")

          (system-description "Turreted 120mm gun, typical of tanks such as the M1A2. Fires M829A1-AP and M830-HEAT rounds. Targets ground vehicles.")

          (allowed-state-repository-types "ground-vehicle-param") (system-categories "weapon")

          (parameter-data-list

          ...)

          (string-parameter-data (parameter-name "slew-group") (variable-type "DtRwString")

          (display-label "Slew Joystick Group Name") (display-units "")

          (source-units "")

          (default-value "weapon:120mm Ballistic Gun")

          )

          (string-parameter-data

          (parameter-name "ballistic-gun-group") (variable-type "DtRwString")

          (display-label "Ballistic Gun Joystick Group Name") (display-units "")

          (source-units "")

          (default-value "weapon:120mm Ballistic Gun")

          )

          ...

          Other weapon systems are configured similarly. On the Joystick Configuration page (Figure 75-8), the Switch Between group lists weapon as an option. The weapons configured for switching all show the switch_option:sysdef syntax.



          image

          Figure 75-8. Switch between option

          For details about using the switch between option, please see “Switching Between Systems,” on page 19-19.


        5. Using Multiple Joysticks

          You can attach multiple joysticks or game controllers to your computer. You must create a configuration for each joystick that you want to use. When you take control of an entity, you select the configuration you want to use and the functions that you want to control with the selected configuration.

          In Figure 75-9, the selected entity (a helicopter) has two functions that can be controlled by joystick or game controller.


          image

          Figure 75-9. Take Control dialog box

          You could select one configuration to control both, or you could control the two func- tions with different controllers, as follows:

          1. Select the entity.

          2. Choose Objects Take Control. The Take Control dialog box opens.

          3. Clear the Rotary Wing Controls check box. This leaves the Gamepad configura- tion controlling the M230 ballistic gun.

          4. Click OK.

          5. Select the entity again and choose Objects Take Control. The Take Control dialog box opens (Figure 75-10). Only the Rotary Wing Controls function is avail- able, because the ballistic gun is already under the control of the Gamepad configu- ration.


            image

            Figure 75-10. Take Control dialog box, one function available

          6. In the Configuration list, select a different configuration Figure 75-11.



            image

            Figure 75-11. Take Control dialog box, second configuration selected

          7. Click OK. The rotary wing controls are now controlled by the Saitek configuration and the ballistic gun by the Gamepad configuration.


        6. Specifying a Favorite Joystick Configuration

          Ordinarily, when you ask to take control of an entity with a joystick, you must specify the joystick configuration to use. You can specify a configuration as the favorite. In that case the configuration is automatically applied. However, you cannot choose a different configuration.

          To specify a favorite joystick configuration:

          1. Choose Settings Application. The Application Settings dialog box opens.

          2. Select the Joystick Configuration page (Figure 75-1).

          3. In the Game Controller Configurations list, select the configuration that you want to specify as the favorite.

            image

          4. Click the Star button ( ). A star is added to the configuration name in the list.


    image

    76. Attaching Components to Remote Entities


    This chapter explains how to configure components on remote entities.

    Attaching VR-Forces Components to Remote Entities 76-2

      1. Attaching VR-Forces Components to Remote Entities

        You can attach VR-Forces sensors, actuators, and controllers to remote (non-VR- Forces) entities. This feature allows you to add to the capabilities of the remote entity and better integrate it with the VR-Forces simulation. For example, you could add a radio to an entity or you could enable spot reporting. When you attach a component to a remote entity, you can write a plan for that entity that uses the attached components. For details, please see “Writing Plans for Remote Entities,” on page 36-39.

        VR-Forces includes an example scenario, remoteAttachment, that uses remote attach- ment. Its use requires that you run an external application, the f18 example that comes with VR-Link. For details about how to run the scenario, please see the readme file in

        ./data/scenarios/remoteAttachment.

        When you add a component to a remote entity, the application that is simulating the entity is responsible for updating its position and health status. VR-Forces simulates the attached components. You can specify that VR-Forces simulate the components on one back-end or across all back-ends.

        Simulation of components on remote entities has the following limitations:

    Components are attached to remote entities on the basis of entries in a component attachment table. The component attachment table provided by VR-Forces is

    ./data/simulationModelSets/<model_set>/extra/componentAttachmentTable.mtl.

    The component attachment table associates entities with attachment key-names. The following is a sample component attachment table:

    (remote-configurations (attachment-entry

    ;; CIS MIG 29

    (attach-by object-type (obj-type 1 (1 2 222 1 2 1 -1))) (key-name "mig29-config")

    )

    (attachment-entry

    ;; US F-18

    (attach-by object-type (obj-type 1 (1 2 225 1 9 -1 -1))) (key-name "f18-config")

    )

    )

    Attaching Components to Remote Entities — Attaching VR-Forces Components to Remote

    Entities

    The entries in this table associate the key-names mig29-config and f18-config with appropriate entity type enumerations. You can also associate a key-name with marking text, as follows:

    (attachment-entry

    (attach-by marking-text “HMMWV 1) (key-name "hmmwv-attachments")

    )

    The key-names in the component attachment table have corresponding entries in

    vrfSim.opd in the remote-configurations block, as follows:

    (remote-configurations (remote-configuration

    (key-name "f18-config")

    (configuration-path "$(remote-config-dir)/f18.mtl")

    )

    (remote-configuration

    (key-name "mig29-config")

    (configuration-path "$(remote-config-dir)/mig29.mtl")

    )

    )

    The key-names are associated with specific configuration files, which by default are located in ./data/simulationModelSets/<model_set>/vrfSim/remoteConfigurations. The configuration files contain the components that are to be attached to the remote entity. For examples, please see the files in the remoteConfigurations directory.


    image

  6. Configuring the Graph- ical User Interface


The chapters in this section describe the display engine, windows, and channels, explain features of the graphical user interface (GUI), and how to configure menus and toolbars.



Section XII - Configuring the Graphical User Interface VR-Forces Users Guide


XII-1

Configuring the Graphical User Interface

image


Section XII - Configuring the Graphical User Interface

XII-2 VT MAK


image 77. Display Engine and Window Management


This chapter explains how to add and configure windows and channels and how to save display engine configurations.

The Display Engine 77-2

Window Types 77-2

Managing Display Engine Configurations 77-2

Adding a Window 77-2

Adding a Channel to a Window 77-4

Removing a Window 77-5

Removing a Channel 77-5

Saving a Display Engine Configuration 77-5

Loading a Display Engine Configuration 77-5

Changing a Window’s Attributes 77-6

Changing a Channel’s Attributes 77-7

Setting the Clipping Planes 77-9

Specifying the Projection Resize Policy Attribute 77-11

Changing a Channel’s Frustum (Field of View) 77-14

Changing the Viewport 77-15

Configuring Water Visibility 77-16

Configuring Multichannel Displays 77-17

Changing the Camera’s Position and Orientation Offset 77-19

Stereoscopic Displays 77-20

Configuring Anaglyphic Stereo 77-21

Configuring Polarized Stereo 77-22

Display Engine and Window Management — The Display Engine

image

    1. The Display Engine

      The VR-Forces front-end has a component called a display engine. The display engine renders 3D and 2D data and can display data in one or more windows, which can each have zero or more channels. The windows and channels being rendered at any partic- ular time make up a display engine configuration. You can save display engine configu- rations and can load them to quickly recreate a particular configuration.


      1. Window Types

        VR-Forces supports the following types of windows:

    2. Managing Display Engine Configurations

      You can add windows to the display engine and you can add channels to the windows. The windows and channels make up a display engine configuration. You can save a display engine configuration and load a saved configuration.


      1. Adding a Window

        You can add as many windows as you want. New windows are named for the window type, for example Stealth Inset 1, Stealth Inset 2, Plan View Inset 1, and so on. Each window is created with one channel. You can add new windows from the File menu or in the Display Engine Configuration Editor.

        To add a window from the File menu, choose File New Stealth Window (or New Plan View Window). A new window opens (Figure 77-1).



        image

        Figure 77-1. New window

        To add a window from the Display Engine Configuration Editor:

        1. Choose View Display Engine Configuration Editor Panel. The Display Engine Configuration Editor Panel is added to the VR-Forces window (Figure 77-2).


          image

          Figure 77-2. Display Engine Configuration Editor Panel

          Display Engine and Window Management — Managing Display Engine Configurations

          image


        2. Select the display engine at the top of the Display tree.

        3. Click the Add a Window button image), or right-click the display engine name and choose Add a Window on the context sensitive menu. A new window opens and is listed in the Display Engine Configuration Editor Panel (Figure 77-3).


        image

        Figure 77-3. New window


      2. Adding a Channel to a Window

        Adding a channel to a window lets you configure multiple views within that window.

        To add a channel to a window:

        1. In the Display Engine Configuration Editor Panel, select the window to which you want to add a channel.

        2. Click the Add a Channel button image), or right-click the window name and choose

        Add a Channel from the menu.


        image

        i

        i

        To see a difference between the channels, change the attributes of the new channel (Figure 77-10). For details about editing channel attributes, please see “Changing a Channel’s Attributes,” on page 77-7.


        image


      3. Removing a Window

        To remove a window:

        1. In the Display Engine Configuration Editor Panel, select the window that you want to remove.

        2. Click the Remove Window button image), or right-click the window name and choose Remove Window from the menu.


      4. Removing a Channel

        To remove a channel:

        1. In the Display Engine Configuration Editor Panel, select the channel that you want to remove.

        2. Click the Remove Channel button image), or right-click the window name and choose Remove Channel from the menu.


      5. Saving a Display Engine Configuration

        You can save a display engine configuration so that you can easily replicate the configu- ration at a later time.

        To save a display engine configuration:

        1. Click the Save Display Engine Configuration button image), or right-click the name of the display engine and choose Save Display Engine Configuration on the menu. The Save Display Engine Configuration dialog box opens.

        2. Type a name for the display engine configuration.

        3. Click Save.


      6. Loading a Display Engine Configuration

        To load a display engine configuration:

        1. In the Display Engine Configuration Editor Panel, select the display engine at the top of the window.

          image

        2. Click the Load Display Engine Configuration button ( ), or right-click the name of the display engine and choose Load Display Engine Configuration on the menu. The Load Display Engine Configuration dialog box opens.

        3. Select the display engine configuration you want to load.

        4. Click Open.

        Display Engine and Window Management — Changing a Window’s Attributes

        image

    3. Changing a Window’s Attributes

      You can change the following attributes of a window:

      To change a window’s attributes:

      1. Select the window in the Display Engine Configuration Editor Panel. A list of attri- butes is displayed at the bottom of the editor (Figure 77-2).

      2. Click the value of the attribute that you want to change.

      3. To change a numeric value, type or select a value.

        To change the Window Type or Fixed Size, select a value from the list. To change the name, type a new name.

      4. Click Commit Changes. The window is updated.


      image

      i

      i

      You can also change a window’s position by dragging it to a new location. You can change its size by resizing the window directly. The new values are shown in the attributes list the next time you select the window in the Display Engine Configuration Editor Panel.


      image


    4. Changing a Channel’s Attributes

      You can change the following attributes of a channel:


      To change a channel’s attributes:

      1. Select the channel in the Display Engine Configuration Editor Panel. A list of attri- butes is displayed at the bottom of the editor (Figure 77-4).


        image

        Figure 77-4. Channel attributes

      2. Click the value of the attribute that you want to change.

      3. To change a numeric value, type or select a new value.

        To change the Observer Name, Sensor, Project Units, Projections Resize Policy, or Parent Channel, select a value from the list.

        To change the Channel Name, type a new name. (For details about some of these attributes, please see the sections that follow this one.)

      4. Click Commit Changes. The window is updated.


      1. Setting the Clipping Planes

        To improve performance, the graphics engine does not render anything that falls outside of a specified range of distances from the observer. This range is determined by the near and far clipping planes. Clipping planes are set on a per-channel basis.

        Figure 77-5 illustrates the effect of changing the near clipping plane (the Z Near attri- bute). Figure 77-6 illustrates the effect of changing the far clipping plane (the Z Far attributes).



        image

        Z Near = 1 Z Near = 500


        Figure 77-5. Near clipping



        image

        Z Far = 10000000 Z Far = 10000


        Figure 77-6. Far clipping


        The ratio between the far clipping plane and the near clipping plane determines the precision with which the renderer can determine differences in depth. If this ratio becomes too small, then terrain and objects that are distant may not sort correctly, resulting in what is referred to as Z-fighting. VR-Forces provides different policies for managing the way near and far clipping planes are determined.

        VR-Forces sets the clipping planes using one of the following policies (the Near Far Clip Policy attribute), plus their modifiers:

      2. Specifying the Projection Resize Policy Attribute

        The Projection Resize Policy determines how a channel behaves when you resize it. The options are:

        • Fixed. Keep the aspect ratio the same regardless of how the window is resized.

        • Horizontal. Maintain the horizontal aspect ratio when the window is resized.

        • Vertical. Maintain the vertical aspect ratio when the window is resized. Figure 77-7 illustrates the effect of different resize policies, as follows:

        • In the window with the fixed resize policy, all of the visual data in the initial view is still in the resized view, although the vertical dimensions are distorted.

        • In the window with the horizontal resize policy, the field of view is widened to maintain the correct aspect ratio of the visual data.

        • In the window with the vertical resize policy, the field of view is shortened.


          You can change the projection resize policy for individual channels by editing the Projection Resize Policy attribute. You can also change the projection resize policy for all channels.


          image

          Initial view


          Resized with Fixed resize policy


          Resized with Horizontal resize policy


          Resized with Vertical resize policy



          Figure 77-7. Effect of different projection resize policies


          To change the projection resize policy for all channels:

          1. Choose Settings Display. The Display Settings dialog box opens.

          2. Select the Render Settings page (Figure 77-8).


            image

            Figure 77-8. Display Settings, Render Settings page

          3. Select an option on the Channel Projection Resize Policy list.


      3. Changing a Channel’s Frustum (Field of View)

        The field of view setting affects perspective in a manner similar to a camera lens.

        A wide field of view creates an effect like that of a wide-angle lens. Objects appear smaller and farther away from the observer, since the observer coverage spans a wider area. Depth distances between objects become exaggerated.

        A narrow field of view creates an effect like that of a telephoto lens. Objects appear larger and closer to the observer, and the overall scene depth appears flattened. The distances between objects appears compressed.

        Figure 77-9 illustrates different field of view settings taken from the same observer loca- tion. The view on the left has frustum values -22.5, 22.5, -22.5, 22.5. The view on the right has the frustum values -10, 10, -10, 10.



        image

        Figure 77-9. Field of view

        To change a channel’s field of view, edit the frustum values in its attributes list.


      4. Changing the Viewport

        When you change the viewport of a channel, you change the portion of the window in which the channel is displayed. This does not change the extents of the scene. A narrow viewport compresses the scene width. A short viewport compresses the height. Figure 77-10 shows a window that has three channels, each with a different viewport. (The arrows show which portion of the window corresponds to each channel.) Notice that each channel has the same field of view.


        image

        Figure 77-10. Window with three channels and three viewports

        Viewports are specified as a percentage of the window from left to right and top to bottom. Figure 77-11 shows the percentage allocation for the viewports in (Figure 77-10).


        0 50% 100%


        Left:

        0

        Left:

        50

        Right:

        50

        Right:

        100

        Top:

        100

        Top:

        100

        Bottom:

        50

        Bottom:

        50

        Left:

        0

        Left:

        50

        Right:

        50

        Right:

        100

        Top:

        50

        Top:

        50

        Bottom:

        0

        Bottom:

        0

        Left:

        0

        Left:

        50

        Right:

        50

        Right:

        100

        Top:

        100

        Top:

        100

        Bottom:

        50

        Bottom:

        50

        Left:

        0

        Left:

        50

        Right:

        50

        Right:

        100

        Top:

        50

        Top:

        50

        Bottom:

        0

        Bottom:

        0

        50%


        0


        Figure 77-11. Viewport configuration


        image

        i

        i

        When you change viewports, the window might not completely refresh. To see the changes, resize the window.


        image


      5. Configuring Water Visibility

The water visibility attributes (along with the surface transparency setting on the Envi- ronment Conditions dialog box, Weather page) are designed to reduce Z fighting. Z- fighting occurs when the altitude of the ocean surface and the depth of the ocean floor are very close to each other, usually around coastlines that have bathymetry data. The likelihood of Z-fighting decreases as the difference between the ocean surface and ocean floor increases, but it increases as the observer’s altitude increases (because the ocean surface and ocean floor are proportionally closer to each other). Therefore there is a dynamic relationship as these factors change.

Adding transparency to the water reduces Z-fighting. The Dynamic Water Visibility Enabled attribute increases transparency automatically as the observer’s altitude increases. Dynamic Water Visibility Maximum specifies the maximum depth to which transparency is added (Figure 77-12).


image

Apply transparency in this area


Ocean surface


Ocean floor


Dynamic Water Visibility Max


Figure 77-12. Dynamic water visibility

Dynamic water visibility is enabled by default. When Dynamic Water Visibility Enabled is True, VR-Forces increases the water visibility depth from the value Surface Transparency setting (at 0 meters altitude), to the maximum value specified at the current Ocean LOD Elevation. The default depth is 75 meters. This value provides reasonable performance given the default Ocean LOD Elevation (5000 meters), the altitude above which VR-Forces stops displaying dynamic ocean. If you change the Ocean LOD Elevation so that dynamic ocean is displayed when the observer is higher than 5000 meters, Z-fighting may increase and you may need to increase the Dynamic Water Visibility Maximum value. (For details about setting the Ocean LOD Elevation, please see “Setting the Ocean LOD Elevation,” on page 55-16.)

There is no performance cost to enabling this attribute when you are not using dynamic ocean. If there are no underwater terrain polygons, these attributes have no effect.


    1. Configuring Multichannel Displays

      People running simulations often want to set up a multichannel configuration using multiple monitors (on one or more computers) to display exercises. Typical configura- tions are a horizontal alignment, which widens the view, and the angled alignment, which surrounds the observer to simulate an out-the-window view (Figure 77-13).

      You could set up these display configurations by having one computer with several monitors attached, or you could have multiple computers, each running a VR-Forces front-end. You might also want to have a 2D view on one monitor and a 3D view on another.


      image image

      image

      image

      Observer Observer

      Figure 77-13. Multi-channel displays (top-down view)

      By default, all windows and channels show the same view of the terrain (Figure 77-15, default window views). Therefore, if you want a setup in which each channel shows a different view of the terrain, you must configure the channels to calculate an offset from the master view.

      The distribution of the view across multiple channels is controlled by the frustum. Figure 77-14 illustrates the default frustum for Channel 1. It has a 60o field of view, from -30o to +30o.


      Top


      -30o

      30o

      30o

      Left


      -30o

      Right

      Bottom


      Figure 77-14. Default frustum for Channel 1

      If you wanted to split the view into, for example, three horizontal channels, you would edit the left and right frustum values for each channel, as shown in Figure 77-15. The field of view is the same: -30o to +30o. However, now each channel shows a 20o

      segment of the total field of view.


      image

      -30o -10o 10o 30o

      Left Right


      Default window views


      image

      Views after changing frustum values


      Figure 77-15. Frustum values for three channels

      Once you configure the windows and channels you need to create the views you want, save the display engine configuration on each computer that you have configured. The next time you run the scenario, load the appropriate display engine configurations on each computer.


      image

      i

      i

      For a multi-monitor configuration to work correctly, use fixed size windows whose size matches the aspect ratio specified by the horizontal and vertical fileds of view and set the projection resize policy to fixed. (For information about the projection resize policy, please see “Specifying the Projection Resize Policy Attribute,” on page 77-11.)


      image


      1. Changing the Camera’s Position and Orientation Offset

        Changing the frustum affects how much of the database is in the view. Changing the camera’s position and orientation affects the point from which you look at the view. For example, imagine you are simulating the view from a vehicle, as in vehicle 1 in Figure 77-16. (The camera location is represented by the binoculars.)

        If you wanted to show the view as experienced by a gunner riding in the back of the vehicle, or in a turret, you would change the X, Y, and Z camera position offsets in the channel’s attribute list (vehicle 2).



        image image image

        1 2 3


        Figure 77-16. Position and orientation offsets

        If you wanted the gunner to look out the rear of the vehicle, you would change its orientation, with the Psi (heading), Theta (pitch), and Phi (roll) Camera Orientation Offsets (vehicle 3).


    2. Stereoscopic Displays

      Stereoscopic display produces realistic three dimensional imagery by showing each of the viewer’s eyes a different image, rendered from that eye’s point of view. A stereoscopic display requires a system that can render two channels, one for each eye, and a method of displaying the correct channel to the correct eye of the viewer. Three common display methods are active stereo, polarized display, and anaglyphic stereo. OpenScene- Graph can support all three of these methods, and since VR-Forces uses OpenScene- Graph for most of its rendering, all three should be possible in VR-Forces.

      • Active Stereo: In an active stereo setup, frames are alternated on the display for the left eye and the right eye, and a pair of shutter glasses blocks light to either the left or right eye in synchronization with the display. This method requires hardware support to synchronize the glasses to the display, along with a graphics card capable of quad buffering, and a display that can refresh at twice the desired frame rate. Active stereo should be possible with VR-Forces, but has not been tested.

      • Anaglyphic Stereo: Anaglyphic stereo is the cheapest and simplest method to use. A typical setup is a display showing a red channel and a cyan channel simultaneously, along with a pair of glasses with one red lens and one cyan lens for the viewer. This will work with no special hardware aside from the inexpensive glasses. It is also the simplest method to set up in VR-Forces, requiring only that some OpenScene- Graph environment variables be set.

      • Polarized Stereo: A polarized display shows the frames for both eyes simultaneously, but with their light polarized in different directions. The viewer wears glasses that have lenses polarized to match the two different frames, allowing each eye to see only the frame intended for it. Polarized stereoscopy requires some specialized equipment to display the images with the correct polarization. One simple method for producing this kind of display is to use two projectors with polarizing filters, projecting onto a rear projection screen. Monitors are available that can polarize the two frames. It is easy to configure a polarized display with VR-Forces.


      1. Configuring Anaglyphic Stereo

You can configure OpenSceneGraph for anaglyphic stereo rendering through environ- ment variables. To use VR-Forces in anaglyphic mode, run it with the environment variables described in Table 77-1.

image

Table 77-1: Environment variables for anaglyphic stereo


Environment Variable Description Default

Environment Variable Description Default

OSG_STEREO Turn stereo on. ON OSG_STEREO_MODE Use anaglyphic stereo when in stereo. ANAGLYPHIC

OSG_SCREEN_DISTANCE Specifies the distance, in meters, that

the viewer is from the screen.

OSG_SCREEN_HEIGHT Specifies the height of the image, in

meters, on the screen.

OSG_SCREEN_WIDTH Specifies the width of the image, in

meters, on the screen.

OSG_EYE_SEPARATION Specifies the eye separation (interoc-

cular distance).

0.50


0.26


0.325


0.06


image


For more information, pleases see the OpenSceneGraph documentation at http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/StereoSettings.


      1. Configuring Polarized Stereo

        You can configure polarized stereo by taking advantage of VR-Forces’s ability to produce multichannel displays. You configure one channel per eye. Each channel renders with a camera that is at a slight offset from the other channel’s camera to repre- sent the spacing between the viewer’s eyes.

        Varying the eye spacing and focal length can produce different effects, and the best values may depend on what the viewer is looking at. Figure 77-17 shows an example configuration.


        image

        Left channel Right channel


        Figure 77-17. Polarized stereo channel configurations


        To compute the correct channel configuration values:

        1. Pick a focal length, L. Objects at this distance will appear to be in the plane of the display. Objects that are further away will appear behind the display, and objects closer will appear in front of it.

        2. Pick an eye spacing, E, to represent the distance between the viewer’s eyes. Human eyes are typically about 0.063m apart1.

        3. Set the X Camera Position values to –E/2 meters for the left channel and E/2

          meters for the right channel.

        4. Set the Psi Camera Orientation values to –arctan(E/2)/L degrees for the left channel and arctan(E/2)/L degrees for the right channel.



image


1. “"Variation and extrema of human interpupillary distance", N. A. Dodgson, Proc SPIE 5291. Select publications link and scroll to 2004 at http://www.cl.cam.ac.uk/~nad10/pubs/EI5291A-05.pdf.


image

78. GUI Controls, Layouts, and Behaviors


This chapter provides details about using the various panels and toolbars in the front- end.

Dockable Panels and Toolbars 78-2

Docking and Undocking a Panel 78-2

Docking and Undocking a Toolbar 78-3

Displaying and Hiding Panels and Toolbars 78-3

Saving Window Layouts 78-3

Creating a Window Layout 78-4

Choosing the Window Layout 78-5

Setting a Window Layout as the Default Layout 78-5

Reverting a Window Layout 78-6

Updating a Window Layout 78-6

Renaming a Window Layout 78-7

Deleting a Window Layout 78-7

Restoring a Factory Layout 78-7

Using Tear-Off Menus 78-8

Viewing the Window in Full Screen Mode 78-9

Using Context-Sensitive Menus 78-9

Common VR-Forces Buttons 78-9

Adding Text to the Title Bar 78-10

Specifying Display Units 78-11

GUI Controls, Layouts, and Behaviors — Dockable Panels and Toolbars

image

    1. Dockable Panels and Toolbars

      VR-Forces has floating, dockable panels for many of its important functions (Figure 78-1). It also has toolbars that let you quickly access the commands available on the menus.


      image


      Figure 78-1. VR-Forces window and undocked panels


      1. Docking and Undocking a Panel

        To undock a panel:

        1. Place the cursor over the panel’s title.

        2. Press and hold the left mouse button.

        3. Drag the panel away from the window.

          To dock a floating panel, double-click its title bar.


      2. Docking and Undocking a Toolbar

        To undock a toolbar:

        1. Place the cursor over the handle.


          image

          Figure 78-2. Toolbar handle

        2. Press and hold the left mouse button.

        3. Drag the toolbar away from the window.

          To dock a toolbar, drag it back to the toolbar strip. The other toolbars will move to create a space to drop in the toolbar (Figure 78-3).


          image

          Figure 78-3. Docking a toolbar


      3. Displaying and Hiding Panels and Toolbars

You can hide any of the panels or toolbars.

To hide or view a panel or toolbar, select it on the View menu.


78.2. Saving Window Layouts

You can save window layouts to named layouts and can easily switch between them while VR-Forces is running. A layout stores the window size and the visibility and loca- tion of all toolbars and panels. You can specify that a layout be the default layout used at startup.

Layouts get saved to ./appData/settings/vrfGui. Each layout is saved to a separate file using the naming convention layout_layout_name.uisx. For backup, you can save layouts to ./factory/settings/vrfGui.

VR-Forces includes two layouts to get you started. The Scenario Creation layout has a set of toolbars and panels that users typically need when creating a scenario. Scenario Viewer removes the toolbars and panels to maximize the amount of the window that displays the scenario.

When you shut down VR-Forces, it saves the window layout. If you do not specify a default window layout, when VR-Forces starts up, it uses the saved window layout.


      1. Creating a Window Layout

        To create a window Layout:

        1. Arrange the toolbars, panels, and window size in the layout you want.

        2. Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).


          image

          Figure 78-4. Layout Manager

        3. Click New. The Layout Name dialog box opens.

        4. Type a name in the Layout Name box.

        5. Click OK.

        6. Select one of the window size options:

          • Maximize. Maximizes the window when this window layout is selected, regard- less of the window size when the layout is created.

          • Restore Window. Save the current window size as part of the window layout.

            This is the default option.

          • Full Screen Mode. Put the window into full screen mode when this layout is selected, regardless of the window size when the layout is created.

        7. Click OK. The layout is added to the list of layouts.


      2. Choosing the Window Layout

        You can easily choose a window layout at any time. You can change layouts from the View menu or from the Layout Manager.

        You can map keys to layouts to select them from the keyboard. Each layout can be mapped to a key (Figure 78-5). For details about mapping keys, please see Chapter 80, Creating and Editing Key Mappings.


        image

        Figure 78-5. Layout action in Key Mapping Editor

        To choose a window layout, choose View Window Layouts layout, where

        layout is one of the listed named layouts.

        To change the window layout in the Window Layout Manager, in the list of layouts, double-click the layout you want to use or select the layout you want and click Switch To.


      3. Setting a Window Layout as the Default Layout

        When VR-Forces starts, if there is a default layout, it uses that layout. Otherwise, it uses the window layout it saved the last time you shut down VR-Forces.

        To set a window layout to be the default layout:

        1. Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).

        2. In the list of layouts, select the layout you want to be the default.

        3. Click Make Default. A star is displayed next to the name of the layout to indicate it is the default layout.


          Clearing the Default Layout

          If you have specified a default layout, you can specify that a different layout be the default or clear it so that there is no default layout.

          To clear the default layout:

          1. Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).

          2. To specify a different default layout, select the desired layout and click Make Default.

          3. To just clear the current default layout, in the list of layouts, select the default layout and click Clear Default.


      4. Reverting a Window Layout

        If you use a named window layout and then rearrange the window, you can revert to the saved layout.

        To revert a window layout, choose View Revert Window Layout. (You can also revert a layout on the Window Layout Manager dialog box.)


      5. Updating a Window Layout

        If you load a window layout and then make changes to the layout, such as resizing the window or closing a panel, VR-Forces does not keep track of the changes. If you switch to a different layout or shut down, the changes are lost. If you want to save changes to a layout, you must explicitly update it.

        To update a window Layout:

        1. Choose View Window Layout Manager. The Window Layout Manager opens (Figure 78-4).

        2. Select the layout you are using.

        3. Click Update.


      6. Renaming a Window Layout

        You can change the name of a window layout.

        To rename a window layout:

        1. Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).

        2. Select the layout you want to rename.

        3. Click Rename. The Layout Name dialog box opens.

        4. Type a new name for the layout.

        5. Click OK.


      7. Deleting a Window Layout

        You can delete window layouts that you have created.

        To delete a window layout:

        1. Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).

        2. Select the layout you want to delete.

        3. Click Delete.


      8. Restoring a Factory Layout

        VR-Forces includes two layouts. They are in ./appData/settings/vrfGui, which makes them available to the Layout Manager. They are also in ./factory/settings/vrfGui so that they can be restored. All layouts created after you install VR-Forces are saved to

        ./appData/settings/vrfGui. If you want to back up your layouts, you can copy them to any backup location you want. If you want to be able to restore a layout in the Layout Manager, copy it to ./factory/settings/vrfGui.

        To restore a layout from the factory, it must be present in ./appData/settings/vrfGui so that you can select it in the Layout Manager. If you delete a layout and then want to recover it, if you have saved a copy of it to ./factory/settings/vrfGui or anyplace else, you can copy it to ./appData/settings/vrfGui.

        To restore a window layout to the factory layout:

        1. Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).

        2. Select the layout you want to restore.

        3. Click Restore From Factory.

GUI Controls, Layouts, and Behaviors — Using Tear-Off Menus

image

    1. Using Tear-Off Menus

      You can “tear-off” the Create menu and leave it displayed on the desktop.

      To tear off the Create menu:

      1. Click the Create menu.

      2. Move the cursor over the grab bar (dashed line) at the top of the menu to highlight it (Figure 78-6).

      3. Right-click. The menu is displayed as a window that you can leave open and repo- sition.


        image

        Figure 78-6. Tearing off a menu

        GUI Controls, Layouts, and Behaviors — Common VR-Forces Buttons

        image

    2. Viewing the Window in Full Screen Mode

      You can display VR-Forces so that it covers the entire screen and does not show the title bar or border. This mode is intended for use in demonstrations. When menus and panels are hidden, you can still use all keyboard controls, and you can still click simula- tion objects in the window to attach the observer to them.

      You can configure VR-Forces to start in full screen mode with the --fullScreen command-line option. If you are viewing a simulation that takes place primarily over the ocean, you may get better performance using the --pseudoFullScreen command-line option.

      To view VR-Forces in full screen mode, choose View Show Full Screen, or press

      Ctrl+Enter.

      To exit full screen mode, press Ctrl+Enter.


    3. Using Context-Sensitive Menus

      VR-Forces has context sensitive menus (also called popup menus or right-click menus) that you can display by clicking the right mouse button.

      If you right-click a simulation object, tactical graphic, or other scene object, the menu displays the actions that you can take.

      If you right-click the menu bar, you can select the commands available on the View menu.


    4. Common VR-Forces Buttons

      VR-Forces dialog boxes have a common set of buttons, as follows:

      image

      • Add an item (definition, model, and so on).

        image

      • Remove the selected item.

        image

      • Copy the selected item and add the copied version to the list.

        image Select a filter of some type.

        image

      • Rename the selected item.

        image

      • Add from a list.

        image

      • Move up in the list.

        image

      • Move down in the list.

        image

      • Select the previous item.

        image

      • Select the next item.

        image Add an attribute.

        image

      • Remove local attribute definition and use the parent’s definition.

      image Search.

      GUI Controls, Layouts, and Behaviors — Adding Text to the Title Bar

      image

    5. Adding Text to the Title Bar

      VR-Forces displays the name of the scenario in the title bar. You can display additional text of your choice if you want to. The text is independent of the scenario. It is an appli- cation-wide setting.

      To add text to the title bar:

      1. Choose Settings Application. The Application Settings dialog box opens.

      2. Select the Session Options page (Figure 78-7).


        image

        Figure 78-7. Session Options page

      3. Select the Use Additional Window Title check box.

      4. Type the text you want to display in the text box.


    6. Specifying Display Units

      You can specify the units used to display coordinate system, distance, altitude, and other measurements. Display units are configured by measurement type. This means that you can use different measurement units for different types of data. You can also specify the number of decimal places for measurement values. When you change a measurement display unit, the changes take effect immediately. They are saved and applied the next time you run VR-Forces.


      image

      i

      i

      The following coordinate system and unit display information is independent of (and therefore not affected by) the settings described in this section:

      • The coordinate system information for the observer location in the Observer Information Panel.

      • Grid line coordinates, units, and precision.


      image


      The types of data and the display objects that they affect are as follows:

      • Coordinate system

      • Distance

      • Altitude

      • Velocity (speed)

      • Acceleration

      • Rotational velocity

      • Orientation (heading).

      Table 78-1 describes the coordinate systems that you can specify.

      image

      Table 78-1: Coordinate systems supported


      Coordinate system Description

      Coordinate system Description

      Latitude/Longitude (degrees:minutes:secon ds)


      Latitude/Longitude (decimal radians)

      Location is displayed as two position fields and one alti- tude field. Displays coordinates in the latitude and longi- tude using the geodetic WGS84 coordinate system. Each angle is displayed in degrees:minutes:seconds with seconds displaying base 10 fractional seconds.

      Location is displayed as two position fields and one alti- tude field. Position coordinates in the latitude and longi- tude using the geodetic WGS84 coordinate system. Each angle is displayed in decimal radians.

      Geocentric Location is displayed as three position fields. Position coor-

      dinates are displayed in the geocentric coordinate system. The position fields are always in meters.

      image


      image

      Table 78-1: Coordinate systems supported


      Coordinate system Description

      Coordinate system Description

      UTM Location is displayed as two position fields and one alti- tude field. Position coordinates are displayed in the Universal Transverse Mercator system. The first position field displays the zone and the x location in meters. The second position field displays the y position in meters.

      MGRS Location is displayed as two position fields and one alti- tude field. Position coordinates are displayed in the Military Grid Reference System. The first position field displays the zone. The second position field displays the grid location. The precision controls the number of digits used in the grid display.

      Database Location is displayed as three position fields. Location is displayed using VR-Forces’s current internal cartesian database system. The position fields are displayed using the current distance units.

      image


      To specify measurement units:

      1. Choose Settings Display. The Display Settings dialog box opens.

      2. Select the Display Units Settings page (Figure 78-8).


        image

        Figure 78-8. Display Units Settings page

      3. Select the measurement unit you want for each option from its list.

      4. Type a precision for each measurement unit in the corresponding box in the Decimal Places column.


image

79. Configuring Toolbars, Dialog Boxes, and Menus

This chapter explains how to specify which menus, menu options, toolbars, and dialog box pages get displayed in the graphical user interface (GUI).

Introduction 79-2

Configuring Menus and Menu Commands 79-2

Configuring Dialog Box Pages 79-3

Configuring Context-Sensitive Menus 79-5

Configuring Toolbars 79-6

Creating Toolbars 79-6

Specifying an Icon for a Toolbar Item 79-7

Locking Main GUI Elements 79-7

Configuring Toolbars, Dialog Boxes, and Menus — Introduction

image

    1. Introduction

      VR-Forces displays menus, menu commands, toolbars, dialog box pages, and popup menus based on the information in an XML configuration file. The default file is

      ./appData/settings/vrfGui/default_guiConfiguration.gui. You can edit this file or create

      alternative GUI configuration files. VR-Forces includes an example of a simple GUI configuration file, ./appData/settings/vrfGui/default_guiSimpleScenarioPlayer.gui, that shows how you might create a highly modified GUI. You can specify an alternative GUI configuration file with the --gui command-line option when you start VR- Forces.

      The elements in the configuration file are fairly self-explanatory. This chapter provides a brief description of the file.


      image

      i

      i

      For those GUI elements that can be rearranged, such as toolbars, the .gui file provides the initial organization of GUI elements. If a user rearranges toolbars, the new layout is saved in the settings file and overrides the .gui file.


      image


    2. Configuring Menus and Menu Commands

      Menus are configured in the <mainmenuconfiguration> element. Each menu is configured in a <mainmenu> element. Menu commands are configured in

      <menuitem> elements. The following example configures a menu bar with one menu that has two items, which are separated by a separator line.

      <mainmenuconfiguration name="main_menu_configuration">

      <mainmenu menuname="DtFileMenu">

      <menuitem itemname="DtNewScenarioMenuItem"/>

      <separator separatorname="1"/>

      <menuitem itemname="DtExitItem"/>

      </mainmenu>

      </mainmenuconfiguration>

      The values for the menuname and itemname attributes must be valid IDs registered in VR-Forces code. default_guiConfiguration.gui has all of the valid IDs for menus and menu commands.

      To remove a menu or menu command from the GUI, delete the applicable element from default_guiConfiguration.gui or create an alternative file that does not have the elements. To add menus or menu items, you must know the ID.

      Configuring Toolbars, Dialog Boxes, and Menus — Configuring Dialog Box Pages

      image

    3. Configuring Dialog Box Pages

      Dialog boxes such as Display Settings and Terrain Settings have multiple pages for configuring different features. The GUI configuration file lets you disable or enable the pages on dialog boxes. The dialog boxes are configured as <pagecollection> elements inside the <pagecollections> element. The following example config- ures the Application Settings dialog box:

      <pagecollections name="page_collections">

      <pagecollection pagecollectionname="DtApplicationSettings" title="Application Settings" location="8" visible="True" index="-1" show="DtKeyMappingEditorPage" closable="True" floatable="True" movable="True">

      <pageitem pageitemname="DtKeyMappingEditorPage"/>

      <pageitem pageitemname="DtMouseMappingEditorPage"/>

      <pageitem pageitemname="DtInterfaceLayoutEditorPage"/>

      <pageitem pageitemname="DtPerformanceOptionsPage"/>

      <pageitem pageitemname="DtSpotReportOptionsPage"/>

      <pageitem pageitemname="DtSessionOptionsPage"/>

      <pageitem pageitemname="DtScriptedTaskOptionsPage"/>

      <pageitem pageitemname="DtEntityBehaviorOptionsPage"/>

      </pagecollection>

      </pagecollections>

      In addition to settings dialog boxes, you can configure the pages on information dialog boxes, and the specific data on the pages. These are configured in

      <informationpagecollection> elements. The following example is part of the Information dialog box. The page is broken up into sections. The first section displays summary data. The second section has the individual pages and specifies the informa- tion on each page.

      <informationpagecollections name="information_page_collections">

      <pagecollection pagecollectionname="DtEntityInformation" title="Entity Information" location="9" visible="True" index="-1" show="DtTaskStatePage" closable="True" floatable="True" movable="True">

      <section sectionname="DtEntityCompactData" maximumHeightIsMinimumHeight="true">

      <informationitem informationitemname="DtEntityIcon" row="0" col="0" rowspan="2" width="50"/>

      <informationitem informationitemname="DtStateMarkingText" row="0" col="1"/>

      <pageitem pageitemname="DtInformationIconBar" row="1" col="1" width="20">

      <informationitem informationitemname="DtEmbarkedOnItem"/>

      </pageitem>

      <informationitem informationitemname="DtCreatePaletteName" row="0" col="2"/>

      <pageitem pageitemname="DtSensorInformationPage" row="1" col="2"/>

      <informationitem informationitemname="DtEntitySpeed" row="0" col="3" width="128"/>

      <informationitem informationitemname="DtEntityAltitude" row="1" col="3" width="128"/>

      <pageitem pageitemname="DtTaskStatePage" row="0" col="4" width="128"/>

      Configuring Toolbars, Dialog Boxes, and Menus — Configuring Dialog Box Pages

      image


      <informationitem informationitemname="DtObjectConsoleInformationStatusItem" row="1" col="4"/>

      </section>

      <section sectionname="DtEntityExpandedData" collapsible="True" tabbed="small" collapsed="True" title="Detailed Information">

      <pageitem pageitemname="DtTaskStatePage"/>

      <pageitem pageitemname="DtEntityInformationPage">

      <informationitem informationitemname="DtEntityLocation"/>

      <informationitem informationitemname="DtEntitySpeed"/>

      <informationitem informationitemname="DtEntityAltitude"/>

      <informationitem informationitemname="DtEntityVelocity"/>

      <informationitem informationitemname="DtEntityAcceleration"/>

      ...

      <informationitem informationitemname="DtEntityStateFrozen"/>

      <informationitem informationitemname="DtEntityStateDRAlgorithm"/>

      </pageitem>

      <pageitem pageitemname="DtEntityAttributesPage"/>

      <pageitem pageitemname="DtResourceInformationPage"/>

      ...

      </section>

      <section sectionname="DtObjectConsoleSection" title="Object Console" collapsible="true" collapsed="true" maximumHeightIsMinimumHeight="true">

      <pageitem pageitemname="DtObjectConsoleInformationWidget"/>

      </section>

      </pagecollection>

      ...

      </informationpagecollections>

      Notice that by default, the DtTaskStatePage does not have any <informationitem> elements. The information on that page is generated dynamically. There are no static fields.

      Configuring Toolbars, Dialog Boxes, and Menus — Configuring Context-Sensitive Menus

      image

    4. Configuring Context-Sensitive Menus

      The Objects menu on the main menu bar and the context-sensitive, or popup, menus vary depending on which objects are selected. These menus are configured as a set of

      <rightclickmenu> elements. There are multiple versions of these elements to account for the different contexts in which a menu might be displayed, for example, one unit, multiple single entities, a mix of entities and control objects. The following example is part of the context-sensitive menu for multiple entities:

      <rightclickmenus name="right_click_menus">

      <rightclickmenu rightclickmenuname="Multiple_Entity">

      <popupmenu menuname="DtVrfRightClickContextMenu">

      <menu menuname="DtRightClickTaskMenu"/>

      <menu menuname="DtRightClickSetMenu"/>

      <separator separatorname="2"/>

      <menuitem itemname="DtVrfEntityAbandonPlanAction"/>

      <menuitem itemname="DtVrfEntityRestartPlanAction"/>

      <menuitem itemname="DtVrfEntityPlanAction"/>

      <menuitem itemname="DtVrfManageReactiveTasksActionId"/>

      <menuitem itemname="DtVrfEntitySkipTaskAction"/>

      <separator separatorname="110"/>

      <menuitem itemname="DtVrfAggregateAsAction"/>

      <menuitem itemname="DtExpandAggregateMenuItem"/>

      <menuitem itemname="DtExpandAllAggregateMenuItem"/>

      <menuitem itemname="DtCollapseAggregateMenuItem"/>

      <menuitem itemname="DtCollapseAllAggregateMenuItem"/>

      <menuitem itemname="DtObjectSettingsAction"/>

      ...

      <menuitem itemname="DtZoomToExtentsAction"/>

      <separator separatorname="DtInformationItemSeparator"/>

      <menuitem itemname="DtVrfVrlinkObjectInformationItem"/>

      </popupmenu>

      </rightclickmenu>

      <rightclickmenus name="right_click_menus">

      Notice that the entries for the Task menu (DtRightClickTaskMenu) and the Set menu (DtRightClickSetMenu) do not have any <menuitem> elements. That is because these menus are themselves context-sensitive and get built dynamically.

      Configuring Toolbars, Dialog Boxes, and Menus — Configuring Toolbars

      image

    5. Configuring Toolbars

      You can configure use of the various toolbars provided with VR-Forces. For each displayed toolbar, you can configure which row it is in and which command icons are used. The following example shows that the Scenario toolbar is in the top row:

      <toolbarconfiguration name="toolbar_configuration">

      <toolbarrow toolbarname="Top_Row">

      <toolbar toolbarname="DtScenarioToolbar" visible="True" floating="False">

      <item itemname="DtNewScenarioMenuItem"/>

      <separator separatorname="DtScenarioToolbar_1"/>

      <item itemname="DtLoadScenarioMenuItem"/>

      <item itemname="DtLoadBatchScenarioMenuItem"/>

      <separator separatorname="DtScenarioToolbar_2"/>

      <item itemname="DtSaveScenarioMenuItem"/>

      <separator separatorname="DtScenarioToolbar_3"/>

      <item itemname="DtCloseScenarioMenuItem"/>

      </toolbar>

      </toolbarrow>

      </toolbarconfiguration>


      1. Creating Toolbars

        Since toolbars are just buttons that reference existing menu options, you can create your own toolbars as easily as you add, delete, or edit the toolbars provided with VR-Forces. Simply add a toolbar element in one of the toolbarrow elements.

        If you want to add tasks or sets to the Task or Set toolbars, or create a new toolbar, specify the itemname using the task or set ID as listed in ./include/vrfGuiCon- stants/vrfMenuIds.h. If you want to add a scripted task to a toolbar, the itemname is its script ID plus “ToolbarItem”. For example, if you add the Place IED scripted task to the Task toolbar, it would look like this:

        <toolbar toolbarname="DtTaskToolbar" visible="True" floating="False">

        <item itemname="DtVrfTaskMoveToActionToolbarItem"/>

        <item itemname="DtVrfTaskMoveToLocationActionToolbarItem"/>

        <item itemname="DtVrfTaskMoveAlongRouteActionToolbarItem"/>

        <item itemname="DtVrfTaskMoveToAltitudeActionToolbarItem"/>

        <item itemname="DtVrfTaskPatrolObjectsActionToolbarItem"/>

        <item itemname="DtVrfTaskPatrolRouteActionToolbarItem"/>

        <item itemname="DtVrfTaskEmbarkActionToolbarItem"/>

        <item itemname="DtVrfTaskDisembarkActionToolbarItem"/>

        <item itemname="Place_IEDToolbarItem"/>

        </toolbar>

        Configuring Toolbars, Dialog Boxes, and Menus — Locking Main GUI Elements

        image

      2. Specifying an Icon for a Toolbar Item

If you add an item to a toolbar, you can associate an icon with the toolbar button. To associate an icon with a scripted task, specify it in the Scripts dialog box. For details, please see “Specifying a Menu Icon,” on page 32-11. For tasks or sets, create an SVG file and put it in ./data/Icons. The file should use the menu ID of the task or set (from

./include/vrfGuiConstants/vrfMenuIds.h) with the DtVrf text and Action text stripped from it. For example, the icon for DtVrfTaskMoveToAltitudeAction is TaskMoveToAlti- tude.svg. The icon for DtVrfSetHeadingAction is SetHeading.svg.


79.6. Locking Main GUI Elements

VR-Forces plug-ins can modify menus, dialog boxes, and other GUI features. You can lock GUI settings for first level elements (elements under the root element). This feature is used in ./appData/settings/vrfGui/default_guiSimpleScenarioPlayer.gui. The syntax would be as follows:

<mainmenuconfiguration name="main_menu_configuration" locked="True">

...

</mainmenuconfiguration>

Given this configuration, none of the menus on the main menu could be modified.

Configuring Toolbars, Dialog Boxes, and Menus — Locking Main GUI Elements

image


image 80. Creating and Editing Key Mappings


This chapter explains how to edit key mappings and create new key mappings.

Introduction 80-2

The Key Mapping Editor 80-3

Binary Key Mappings 80-4

Editing a Key Map 80-4

Adding a Key Mapping 80-5

Changing a Key Mapping 80-7

Deleting a Key Mapping 80-7

Using Combined Key Mappings 80-8

Filtering the Function List 80-9

Creating a Key Map 80-9

Deleting a Key Map 80-9

Creating and Editing Key Mappings — Introduction

image

    1. Introduction

      When you move the observer, you are actually executing functions that control the observer’s movement. For example, the Move Observer Forward function moves the observer forward in observer coordinates. The Move Level Observer Forward function moves the observer forward in level observer coordinates.

      The various movement functions are mapped to the keys on the keyboard and to mouse buttons and the mouse wheel.

      VR-Forces comes with key mappings that we think will meet the needs of most VR- Forces users. However, you can edit the default keyboard mappings and create new mappings of your own with the Key Mapping Editor.

      Creating and Editing Key Mappings — The Key Mapping Editor

      image

    2. The Key Mapping Editor

      The Key Mapping Editor (Figure 80-1) lists all of the functions that you can control from the keyboard and the keys to which they are mapped. Some functions are mapped to more than one key or key combination. A key can be mapped to more than one function (combined mappings). You can:

      • Edit a function’s key mappings.

      • Add new mappings.

      • Delete mappings.

Changes are saved automatically.


image

Figure 80-1. Key Mapping Editor


80.2.1. Binary Key Mappings

Many navigation functions require you to press and hold a key. For example, you press and hold W to move the observer forward. (By contrast some keyboard actions are toggles or unary functions, such as pressing period to attach to the next simulation object.) For these actions, VR-Forces needs to keep track of when the key is pressed down (start the action) and when it is released (stop the action). To a human user, a function like Move Observer Forward is experienced as one action. But the computer experiences it as two actions. Therefore, key mappings must take this into account. The Key Mapping Editor shows the key mappings for these functions as paired functions that are subordinate (children) to the primary function (the parent), as shown in the Move Observer Up entry in Figure 80-1.


    1. Editing a Key Map

      The Key Mapping Editor lists all of the VR-Forces functions that you can control from the keyboard.

      To edit a key map:

      1. Choose Settings Application. The Application Settings dialog box opens.

      2. Select the Key Mapping Editor page (Figure 80-1).

      3. Select the function whose key mappings you want to edit.

      4. Edit the key mappings as described in:

      5. Optionally, export the key map to a file.

      6. Click OK.


            1. Adding a Key Mapping

              If a function is not mapped to a key, it is marked <unmapped>. You can add a mapping to unmapped functions and you can add additional key mappings to functions that are already mapped. If you add a key mapping to a binary function, the Key Mapping Editor automatically applies it to the child (UP and DN) functions. You can add key mappings to the child functions of binary mappings. When you add a key mapping to a child function, it is not applied to its paired function or the parent function.


              image

              i

              i

              In most cases, an unmapped function is unmapped because it is not meaningful in the observer frame for the key mapping. For example, the level observer movement functions are not meaningful in the observer frame key mappings.


              image


              To add a key mapping:

              1. Optionally, filter the function list. For details, please see “Filtering the Function List,” on page 80-9.

              2. Select the function to which you want to add a key mapping.

                image

              3. Click the Add button ( ) above the Key Map window (Figure 80-2). The Key Entry dialog box opens (Figure 80-3).


                image

                Function list Key mappings Key Map



                Figure 80-2. Key Mapping Editor


                image


                Figure 80-3. Key Entry dialog box

              4. On the keyboard, press the key or key combination (such as Ctrl+key or

                Shift+key) that you want to map to this function.

              5. Click OK. (If you choose a key combination that is already in use, VR-Forces noti- fies you and asks how to proceed. For details about duplicate key mappings, please see “Using Combined Key Mappings,” on page 80-8.) The mapping is added to the function and is listed in the Keys column of the function list and in the Key Map window.


            2. Changing a Key Mapping

              If a key mapping is assigned to a binary function, the key is automatically assigned to the child functions. You cannot edit the key mappings for the child functions. You can only change the parent’s key mapping. However, if you add a key mapping to a child function, you can edit it.

              To change a key mapping:

              1. Select the function whose key mapping you want to change. Its key mappings get listed in the Key Map window (Figure 80-2).

              2. In the Key Map window, select the key mapping that you want to change.

              3. Click the Edit Key Mapping button image). The Key Entry dialog box opens (Figure 80-4). It shows the current key mapping.


                image

                Figure 80-4. Key Entry dialog box

              4. On the keyboard, press the key or key combination (such as Ctrl+key or

                Shift+key) that you want to map to this function.

              5. Click OK. The mapping is changed.


            3. Deleting a Key Mapping

              To delete a key mapping:

              1. Select the function whose key mapping you want to delete. Its key mappings get listed in the Key Map window (Figure 80-2).

              2. In the Key Map window, select the key mapping that you want to delete.

                image

              3. Click the Delete button ( ) above the Key Map window. The mapping is deleted. The function list is updated.

        Creating and Editing Key Mappings — Using Combined Key Mappings

        image

    2. Using Combined Key Mappings

      You can assign a key combination to more than one function. This allows you to combine the behaviors of two or more functions into one key combination. For example, the Z key detaches the observer from the attached simulation object. The Space Bar resets the observer view to the default view. Suppose that whenever you detach from a simulation object, you want the observer to return to the default view. You could map the Reset function to Z. Z is now mapped to two functions. When you press Z, VR-Forces detaches from the attached simulation object and moves the observer to the default view.

      To manage combined key mappings:

      1. Add the appropriate key mapping to a function.

      2. Click OK. The Key Already Mapped dialog box opens (Figure 80-5). It lists the functions that already use this key mapping.


        image

        Figure 80-5. Key Already Mapped dialog box

      3. If the functions listed are the ones with which you want to share this key mapping, click Add. The key mapping is added to the function.

      4. If you do not want to share this key mapping with other functions and want to use it for the function that you are editing, click Replace. The key mapping is applied to the function you are editing and removed from the functions listed in the dialog box.

      5. If you do not want to remove the key mapping from existing functions and do not want to share it with the other functions, click Cancel. Presumably you wanted a unique key mapping for the function you are editing and did not realize you chose one that was already in use. Choose a different key mapping for this function.

        Creating and Editing Key Mappings — Deleting a Key Map

        image

    3. Filtering the Function List

      You can filter the function list in the Key Mapping Editor. Functions are grouped thematically.

      image

      To filter the function list, click the Filter button ( ) and select an option on the list.


    4. Creating a Key Map

      To create a key map:

      1. Choose Settings Application.The Application Settings dialog box opens.

      2. Select the Key Mapping Editor page (Figure 80-1).

        image

      3. Click the Add button ( ). The Create New Key Map dialog box opens.

      4. Type a name for the new key map.

      5. Click OK.

      6. Add key mappings for the movement actions as described in “Adding a Key Mapping,” on page 80-5.


    5. Deleting a Key Map

      To delete a key map:

      1. Choose Settings Application.The Application Settings dialog box opens.

      2. Select the Key Mapping Editor page (Figure 80-1).

      3. In the key mapping list, select the key mapping that you want to delete.

        image

      4. Click the Delete button ( ).

      5. Confirm that you want to delete the selected key map.

Creating and Editing Key Mappings — Deleting a Key Map

image


image XIII. Configuring Visual Models in the Visual Models Editor


When VR-Forces discovers a simulation object (entity or unit) on the network, it must decide how to represent it in the GUI. This is accomplished by mapping 3D models and 2D icons to object type enumerations. The chapters in this section explain how models and iconography are configured and mapped to object types.


XIII.1. Introduction to Object Modeling

The objects that VR-Forces can display that are not part of the terrain, such as simula- tion objects, tactical graphics, detonations, and cockpit displays, are generically called scene elements. Scene elements are defined in element definitions. When VR-Forces runs a scenario, it publishes information about the objects it is simulating. It may also receive object information over the network from other simulation participants. The objects are identified using object type enumerations. VR-Forces maps these object types to element definitions. (For more information about object type enumerations and mapping them to element definitions, please see “Introduction to Object Type Mapping,” on page 82-2.)

An element definition is a set of visual definitions that tell VR-Forces how to render (display) the object. Visual definitions specify the 3D model, 2D icon, or graphic, and the visual effects that the object supports, such as trailing effects, height-above-terrain lines, track histories, and so on. A scene element can have up to three different element definitions – one for each model set (3D, 3D Colorized, 2D Icon). VR-Forces chooses the correct element definition to use based on the model set being used by the observer. (For more information about model sets, please see “Model Sets,” on page 80-6.)

Element definitions are created and edited in the Visual Model Editors dialog box. In addition to letting you manage element definitions, this dialog box lets you create and manage model definitions and schemas. Model definitions specify values for some basic object parameters. Most importantly for most VR-Forces users, model definitions specify the 3D model to use for element definitions in the 3D Models model set. What this means is that if you want to add a new model to VR-Forces, you will specify the model file, such as an OpenFlight file, in a model definition and then specify that model definition in the element definition for the simulation object you want to add.


image

i

i

The chapters that discuss how to configure visual models do so in the context of using the Visual Models Editor dialog box. We strongly recommend that whenever possible you use the Simulation Object Editor to add and configure visual models. The only time that you should have to use the Visual Models Editor dialog box is if you need to add a new schema or edit model attributes that are not supported by the Simulation Object Editor. For details about how to use the Simulation Object Editor, please see Section XI, Creating and Editing Simulation Models and the chapters in that section.


image


Section XIII - Configuring Visual Models in the Visual Models Editor

XIII-2 VT MAK


Schemas define the most basic scene elements, such as an entity, SpeedTree tree, or line. Most VR-Forces users will never have to create or edit a schema. However, if you create a new model definition, you must make sure it uses the correct schema and that it includes all required parameters.

Figure 80-1 illustrates these relationships using an M1A2 entity. VR-Forces receives the object type 1:1:225:1:1:3:-1 over the network (callout 1). In the Simulation Object Type Mappings dialog box, this object type is mapped to the M1A2 Abrams entity defi- nition (2). (An entity definition is a specific type of element definition.) The M1A2 Abrams entity definition (in the Visual Model Editors dialog box) specifies all of the visual definitions for this entity (3). The Main Model visual definition has a modeldefini- tion parameter. The value for this parameter is TrackedM1A2DESERT. The TrackedM1A2DESERT model definition has a filename parameter that specifies M1A2.medf as the model to use for entities that use this model definition (4). The TrackedM1A2DESERT model definition has a filename parameter because it uses the Entity schema and the Entity schema requires a filename (5).


image

i

i

When you add simulation objects and other scene elements in the Simulation Object Editor, it creates model definitions and handles all of the mappings described in the previous paragraphs and the illustration. Although this manual explains all of the details of the Visual Model Editors dialog box and Simulation Object Type Mappings dialog box, using the Simulation Object Editor to add simulation objects is the preferred method.


image


image

DIS or HLA network


1 1:1:225:1:1:3:-1


2


3


4


5



Figure 80-1. Element definitions and simulation object type mapping


Section XIII - Configuring Visual Models in the Visual Models Editor

XIII-4 VT MAK


      1. Model Formats for 3D Entities, Objects, and Effects

        VR-Forces includes 3D models for vehicles, lifeforms, environmental objects, and effects. The models are in a compressed, encrypted format (extension .medf).


        image

        i

        i

        VR-Forces includes a utility, the MEDF Tool, that lets you encrypt files in MEDF format. You cannot use it to decrypt encrypted files. For more information, please see “Compressing Model Files,” on page 83-27.


        image


        You can provide your own models if they are in one of the following supported formats:

        • OpenFlight.

        • 3ds.

        • OBJ.

        • COLLADA (.dae).

        • OSG (.osg, .osgb, and .ive).

        • NewTek LightWave (.lwo and .lws).

        • MAK GDB.


      2. Model Sets

        The model or icon that is used for an object is determined by its element definition. For convenience, element definitions are organized into model sets. For example, all of the element definitions that specify 3D models are in the 3D Models model set, and so on. As a result, when you choose the 3D Models model set for an observer mode, all of the entities use a 3D model. (The model set is an observer-specific setting.)

        VR-Forces includes the following types of object models and icons:

        • 3D Models. Realistic 3D models. This is the default model set for the Stealth observer mode.

        • 3D Colorized Models. 3D colorized models are cartoon-like models that create an exaggerated notional view of the world. This is the default model set for XR observer mode.

        • 2D Icons. 2D MIL-STD 2525B font-based icons. This is the default model set for the Plan View observer mode. You can also configure VR-Forces to use 2525a images or any arbitrary images for 2D icons.


image

i The model sets are fixed. You cannot add model sets.

image

For information about changing model sets, please see “Changing the Model Set,” on page 48-11.


Section XIII - Configuring Visual Models in the Visual Models Editor

XIII-6 VT MAK


image 81. Model and Element Definitions


In Section XIII, “Configuring Visual Models in the Visual Models Editor,” we describe the interplay of schemas, model definitions, simulation object definitions, and model mapping. This chapter explains how to create and edit model definitions and model schemas. “Adding a Model to VR-Forces,” on page F-2 walks you through the process of adding a model.

Managing Model and Element Definitions 81-3

Creating and Editing Schemas 81-4

Creating Schemas 81-5

Deleting Schemas 81-6

Copying Schemas 81-6

Adding a Parameter to a Schema 81-7

Deleting a Parameter from a Schema 81-8

Editing a Schema Parameter 81-8

Creating and Editing Model Definitions 81-9

Work Flow Issues for Creating and Editing Model Definitions 81-10

Creating a Model Definition 81-12

Deleting a Model Definition 81-13

Copying a Model Definition 81-14

Filtering the List of Model Definitions 81-15

Editing a Model Definition 81-15

Saving Model Definitions 81-18

Importing Model Definitions 81-19

Exporting Model Definitions 81-20

Creating and Editing Element Definitions 81-21

How Entity, Unit, and Tactical Graphics Element Definitions are Organized 81-21

image

Model and Element Definitions

Work Flow Issues for Creating and Editing Element Definitions 81-23

Creating an Element Definition 81-24

Editing an Element Definition 81-25

Deleting an Element Definition 81-32

Saving Element Definitions 81-32

Importing Element Definitions 81-33

Exporting Element Definitions 81-35

Model and Element Definitions — Managing Model and Element Definitions

image

    1. Managing Model and Element Definitions

      This chapter explains how to use the Visual Model Editors dialog box to create and edit schemas, model definitions, and element definitions. This process can be rather complex. If you are customizing the visual characteristics of the simulation objects provided with VR-Forces or adding new object types that are significantly different from those provided with VR-Forces, you may need to create new model definitions or edit the existing ones. However, if you just need to add new object types that are similar to existing ones, it is strongly recommended that you do so in the Simulation Object Editor.

      When you create a simulation object in the Simulation Object Editor, it adds new model definitions and object type mappings automatically. You will not need to do anything in the Visual Models Editor to configure the new simulation object.

      Model definitions and element definitions (visual definition files) are SMS-specific. The visual definition files for the SMSs provided with VR-Forces are stored in subdirec- tories of ./appData/definitions. If you create a new SMS, the visual definition files are stored as part of the SMS, in ./data/simulationModelSets/<sms>/gui/visuals. You can copy the visual definition files for the provided SMSs into the SMS hierarchy if you want to make it easier to copy an SMS to another VR-Forces installation.

      When you open the Visual Models Editor, it loads the visual model definitions for the SMS used by the loaded scenario. If no scenario is loaded, it defaults to EntityLevel.sms. For details about how to edit visual models in the Simulation Object Editor, please see “Editing a Simulation Object’s Visual Model,” on page 65-19


    2. Creating and Editing Schemas

      The elements that make up a scene have parameters that help define them, for example a model filename. The set of parameters for a particular scene element is a schema. VR- Forces uses schemas to validate element definitions. You can create, copy, and delete schemas. For any schema, you can add and delete parameters and edit parameter values.


      image

      i

      i


image


Model definition schemas define the elements that can be displayed in a scene. The model definition schemas provided with VR-Forces are:


      1. Creating Schemas

        To create a schema:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Schema Editor page (Figure 81-1).


          image

          Figure 81-1. Schema Editor page

          image

        3. Click the Add button ( ) next to the Schemas label. The Create Instance dialog box opens (Figure 81-2).



          image

          Figure 81-2. Create Instance dialog box

        4. Type a name for the new schema.

        5. Click OK.

        6. Add parameters as described in “Adding a Parameter to a Schema,” on page 81-7.


      2. Deleting Schemas


        image

        i

        i

        If a schema is used by a model definition, you cannot delete it. The Delete Schema button will be unavailable.


        image


        To delete a schema:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Schema Editor page (Figure 81-1).

        3. In the Schemas list, select the schema you want to delete.

          image

        4. Click the Delete button ( ) next to the Schemas label. You are prompted to confirm the deletion.

        5. Click Yes. The schema is removed from the list.


      3. Copying Schemas

        If you want a new schema that is a variant of an existing one, it can be easier to copy the existing schema and edit it than it is to create a new schema and add all of the parame- ters.

        To copy a schema:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Schema Editor page (Figure 81-1).

        3. Select the schema that you want to copy.

          image

        4. Click the Duplicate button ( ). The Duplicate Schema dialog box opens.

        5. Type a name for the copied version of the schema.

        6. Click OK.

        7. The new schema is added to the list.

        8. Edit the parameters as described in “Editing a Schema Parameter,” on page 81-8.


      4. Adding a Parameter to a Schema

        To add a parameter to a schema:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Schema Editor page.

        3. In the Schemas list, select the schema to which you want to add a parameter.

          image

        4. Click the Add button ( ) next to the Entries label. A parameter called “key” is added to the parameter list (Figure 81-3).


          image

          Figure 81-3. New schema parameter

        5. Double-click “key”. The Rename Parameter dialog box opens.

        6. Type a name for the parameter.

        7. If the parameter has a specific type, click the value in the Type column and edit it.

        8. If the parameter is required, click the value in the Required column and change it to True.

        9. Optionally, add a description. The description provides context sensitive help on the element definition pages. To add a description:

          1. Click the empty field in the Description column. The Edit Text dialog box opens.

          2. Type the descriptive text.

          3. Click OK.


      5. Deleting a Parameter from a Schema


        image

        !

        !

        If you delete a parameter from a schema, any element definitions that use the schema may become invalid. Invalid element definitions are shown in red in the list of definitions.


        image


        To delete a parameter from a schema:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Schema Editor page (Figure 81-1).

        3. In the Schemas list, select the schema from which you want to delete a parameter.

        4. Select the parameter that you want to delete.

          image

        5. Click the Delete button ( ) next to the Entries label.


      6. Editing a Schema Parameter

        To edit a parameter for a schema:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Schema Editor page (Figure 81-1).

        3. In the Schemas list, select the schema for which you want to edit a parameter.

        4. Click the parameter attribute that you want to edit. The attribute becomes edit- able.

        5. Type the new attribute value.


    1. Creating and Editing Model Definitions

      Many of the visual definitions in an element definition have a model definition param- eter. A model definition specifies a set of parameters that are appropriate to the object type. (The parameters are determined by the model definition’s schema. For informa- tion about model schemas, please see “Creating and Editing Schemas,” on page 81-4.) For most VR-Forces users, the most important thing to know about model definitions is that for 3D models, the model definition specifies the 3D model, such as an Open- Flight file, that is used to display an entity. If you want to add new models to VR- Forces, you will probably have to create a new model definition for each one.


      image

      !

      !

      It is strongly recommended that you use the Simulation Object Editor to edit visual models, which includes the model definition.


      image


      VR-Forces comes with an extensive set of model definitions that are mapped to the included models. You can edit or delete these model definitions and you can create new ones.

      Model definitions are created and edited on the Model Definition Editor page of the Visual Model Editors dialog box (Figure 81-4).


      image

      Figure 81-4. Model Definition Editor page

      The model definitions provided with VR-Forces are stored in ./appData/defini- tions/ModelDefinitions. When you open the Visual Model Editors dialog box, it reads the files in this directory in alphabetical order. If files contain duplicate entries, the entry in the last file loaded takes precedence. You can use command line options to change the location of the model definitions that get loaded at startup. For details, please see “Importing Model Definitions from the Command Line,” on page 81-19.


      image

      i

      i


image


      1. Work Flow Issues for Creating and Editing Model Definitions

        A default VR-Forces installation has multiple model definition files. When you start VR-Forces they all get loaded. When you open the Visual Model Editors dialog box, all of the model definitions are listed. However, the editor does not keep track of which model definitions come from which model definition file. When you create or edit model definitions, VR-Forces does not automatically save them. Therefore, you are responsible for saving new and edited model definitions to the correct location.

        The default model definition files are:

      2. Creating a Model Definition


        image

        !

        !

        VR-Forces does not save changes to model definitions automatically. If you want to keep changes, you must export them to a file.


        image


        To create a model definition:

        1. Decide if you want to export the new model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)

        2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        3. Select the Model Definition Editor page (Figure 81-4).

        4. If you want to export the new model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Defi- nitions,” on page 81-19.)

        5. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

          image

        6. Click the Add button ( ) next to the Model Definitions label. The Add Model Definition dialog box opens (Figure 81-5).


          image

          Figure 81-5. Add Model Definition dialog box

        7. Type a name for the new model definition.


          image

          !

          !

          Model definitions for DI-Guy characters must end with the letters DIG. Model definitions for SpeedTrees must end in ST.


          image


        8. In the Schema list, select a schema for the model. (This list matches the list of schemas on the Schemas page.)

        9. Add parameters to the model, as described in “Adding Parameters to a Model Defi- nition,” on page 81-15.

        10. Export the model definition. (For details, please see “Exporting Model Defini- tions,” on page 81-20.)


      3. Deleting a Model Definition

        If you want to delete a model definition, you have to delete it from its original model definition file. Since the Visual Model Editors dialog box loads multiple model defini- tion files when it starts up, you must be sure that you only load the model definition file that you want to edit.


        image

        i If a model definition is being used, you cannot delete it.

        image

        To delete a model definition:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Model Definition Editor page (Figure 81-4).

        3. Click the Import and Replace button image). The Import Model Definitions dialog box opens.

        4. Select the model definition file you want to import.

        5. Click Open.

        6. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

        7. Select the model that you want to delete.

          image

        8. Click the Delete button ( ) next to the Model Definitions label. You are prompted to confirm the deletion.

        9. Click Yes. The model definition is removed from the list.

        10. Click the Export All button image). The Export Model Definitions dialog box opens.

        11. Select the model definitions file to save to.

        12. Click Save.


      4. Copying a Model Definition

        If you want a new model that is a variant of an existing one, it can be easier to copy the existing model and edit it, than to create a new model and add all of the parameters.


        image

        !

        !

        VR-Forces does not save changes to model definitions automatically. If you want to keep changes, you must export them to a file.


        image


        To copy a model definition:

        1. Decide if you want to export the new model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)

        2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        3. Select the Model Definition Editor page (Figure 81-4).

        4. If you want to export the new model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Defi- nitions,” on page 81-19.)

        5. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

        6. Select the model that you want to copy.

          image

        7. Click the Duplicate button ( ). The Duplicate Model Definition dialog box opens (Figure 81-6).


          image

          Figure 81-6. Copy model definition

        8. Type a name for the copied version of the model.

        9. Click OK.

        10. The new model definition is added to the list.

        11. Edit the parameters as described in “Editing a Model Definition,” on page 81-15.

        12. Export the model definition. (For details, please see “Exporting Model Defini- tions,” on page 81-20.)


      5. Filtering the List of Model Definitions

        By default, the Model Definition Editor page lists all models that VR-Forces knows about. You can filter the list to more easily work with a specific type of model.

        image

        To filter the list of model definitions, click the Filter button ( ) and select a schema type from the list.


      6. Editing a Model Definition

        You can add parameters to a model definition, you can delete parameters, and you can change their values. You can only add parameters that are appropriate to the schema type for a model.


        image

        !

        !

        VR-Forces does not save changes to model definitions automatically. If you want to keep changes, you must export them to a file.


        image


        Adding Parameters to a Model Definition

        When you create a new model definition, you must specify the parameters required by its schema. You can only add parameters that are permitted by the schema.

        To add a parameter to a model:

        1. Decide if you want to export the edited model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)

        2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        3. Select the Model Definition Editor page (Figure 81-4).

        4. If you want to export the edited model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Definitions,” on page 81-19.)

        5. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

        6. Select the model for which you want to add a parameter.

          image

        7. Click the Add Parameter button ( ). A list of parameters is displayed (Figure 81-7).



          image

          Figure 81-7. Add parameter list

        8. Select the parameter you want to add. It is added to the parameter list.

        9. Click the value for the parameter. The field becomes editable (Figure 81-8).


          image

          Figure 81-8. Editable parameter

        10. Type or select a value for the parameter.

        11. Click away from the field.

        12. When you have finished editing the model definition, export it. (For details, please see “Exporting Model Definitions,” on page 81-20.)


          Editing a Model Definition Parameter

          To edit a parameter:

          1. Decide if you want to export the edited model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)

          2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

          3. Select the Model Definition Editor page (Figure 81-4).

          4. If you want to export the edited model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Definitions,” on page 81-19.)

          5. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

          6. Select the model for which you want to edit a parameter.

          7. Click the value for the parameter you want to edit. The field becomes editable (Figure 81-8).

          8. Change the value for the parameter.

          9. Click away from the field.

          10. When you have finished editing the model definition, export it. (For details, please see “Exporting Model Definitions,” on page 81-20.)


        Deleting Parameters from a Model Definition

        If you want to delete parameters from a model definition, you must export the changes back to the original file.


        image

        !

        !

        If you delete a parameter from a model definition, the definition may become invalid. Invalid model definitions are shown in red.


        image


        To delete a parameter from a model:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Model Definition Editor page (Figure 81-4).

        3. Use the Load and Replace procedure to load the model definition file that has the model definition you want to edit.

        4. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

        5. Select the model from which you want to delete a parameter.

        6. Select the parameter that you want to delete.

          image

        7. Click the Delete button ( ) next to the Entries label. The parameter is removed.

        8. Export the model definition to the original model definition file using Export All. (For details, please see “Exporting Model Definitions,” on page 81-20.)


      7. Saving Model Definitions

        If you add, edit, or delete model definitions, you must explicitly export the new or updated definitions to a file. For details, please see “Exporting Model Definitions,” on page 81-20.


      8. Importing Model Definitions

        You can import model definitions and replace the loaded model definitions. You can import model definitions and merge them with the loaded model definitions. For details about how merging works, please see “Managing VR-Forces Settings,” on page 4-21.

        To import model definitions and replace the existing definitions:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Model Definitions page.

        3. Click the Import and Replace button image). The Import Model Definitions dialog box opens.

        4. Select the model definition file you want to import.

        5. Click Open.

        To merge model definitions:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Model Definitions page.

          image

        3. Click the Import and Merge button ( ). The Merge Model Definitions dialog box opens.

        4. Select the model definition file you want to merge.

        5. Click Open.


        Importing Model Definitions from the Command Line

        You can merge in model definitions with the --mergeModelDefs {directory | filename} command-line option. If you specify a directory, VR-Forces merges all model definition files in the directory. If you specify a file, it just merges that file. You can have multiple instances of this option in a command.

        You can specify that VR-Forces not load the model definitions in the ./appData/defini- tions directory. To do this, start VR-Forces with the --noAppDataModelDefs command-line option.


      9. Exporting Model Definitions

You can export all model definitions and you can export individual model definitions. This allows you to create your own library of custom model definitions that you can easily migrate to newer releases of VR-Forces or copy to other VR-Forces installs.


image

!

!

The list of model definitions in a default VR-Forces installation is created by merging multiple model definition files. If you export all model definitions, they do not get exported back to their original files. They get exported to the file you select.


image


To export all model definitions:

  1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

  2. Select the Model Definition Editor page (Figure 81-4).

  3. Click the Export All button image). The Export Model Definitions dialog box opens.

  4. Select the model definitions file to save to or type a new file name.

  5. Click Save.


Exporting Selected Model Definitions

To export selected model definitions:

  1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

  2. Select the Model Definition Editor page (Figure 81-4).

  3. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

  4. Select the model definitions you want to save.

  5. Click the Export Selected button image). The Export Model Definitions dialog box opens.

  6. Select a file or type a name for the model definition file.

  7. Click Save.


    1. Creating and Editing Element Definitions

      Element definitions define how VR-Forces renders scene elements (simulation objects, tactical graphics, interactions, cultural features, spot reports, and so on).


      image

      !

      !

      It is strongly recommended that you use the Simulation Object Editor to edit visual models, which includes the element definition.


      image


      Element definitions are organized in a tree-style hierarchy. At any level of the hierarchy an element definition inherits the visual definitions of its parents. This makes it possible to assign a visual definition to many elements at one time. You can change the inherited parameter values for a specific element at any level of the hierarchy. However, in most cases, you cannot delete an inherited visual definition.

      You can create and edit element definitions. The procedures are the same for each element type except for the save procedure. Element definitions are not saved automat- ically. You must save them explicitly.


      image

      i

      i

      If you edit an element definition in the Simulation Object Editor and save the change, you can update an open scenario to use the new element definition. For details, please see “Reloading Visual Models in the VR-Forces GUI,” on page 65-27.


      image


      1. How Entity, Unit, and Tactical Graphics Element Definitions are Organized

        Entity, unit, and tactical graphics element definitions are stored in two types of files, a hierarchy file (.hier) and one or more leaf definition files (.leaf). The hierarchy file contains the hierarchy of categories for the element definitions, such as Entity Surface Boat and the attribute inheritance information associated with each level of the hierarchy. The leaf files contain the definitions for each element at the leaf level1.

        Other types of element definitions do not save separate hierarchy and leaf files. They are saved to a file with the extension .elem.

        When you add or edit entity, unit, and tactical graphics element definitions, you must save the changes to the hierarchy and leaf files separately. If you have only made leaf level changes, you do not have to save the hierarchy file.



        image


        1. Technically, the leaf level of a tree structure is a node with no children. For element definitions, the leaf level consists of specific definitions. A category that has no members would be part of the hierar- chy, not the leaf file.


          You can create multiple hierarchy and leaf level files to meet your needs. However you can only load one hierarchy file at a time. When VR-Forces starts up, it loads the files in the various element definition directories. If it finds more than one hierarchy file for an element type, it only loads the first one (in alphabetical order). If it finds multiple leaf files, it loads them in alphabetical order. If there are any duplicate entries, the last file loaded takes precedence.


          Leaf File Descriptions

          The element definitions for entity, unit, and tactical graphics are organized into multiple leaf files. This organization is to accommodate the different models in the AggregateLevel and EntityLevel SMSs. The element definitions are organized as follows:

          • ./appData/definitions/Aggregate/ElementDefinitions. Element definitions for hierar- chical units such as platoons and companies:

            • EntityLevelAggregateElementDefinitions.leaf. Units used in entity-level scenarios.

            • coreAggregateElementDefinitions.leaf. Element definitions for objects that do not have .entity files.

            • AggregateLevelAggregateElementDefinitions.leaf. Units used in aggregate-level scenarios.

            • baseAggregateElementDefinitions.leaf. Unit elements used in both entity-level and aggregate level scenarios.

          • ./appData/definitions/Entity/ElementDefinitions. Element definitions for individual simulation objects such as humans, ships, and cars:

            • EntityLevelEntityElementDefinitions.leaf. Element definitions used in entity-level scenarios.

            • coreEntityElementDefinitions.leaf. Element definitions for objects that do not have .entity files.

            • baseEntityElementDefinitions.leaf. Element definitions used in both entity-level and aggregate level scenarios.

          • ./appData/definitions/TacticalGraphics/ElementDefinitions. Element definitions for tactical graphics:

            • EntityLevelTacticalGraphicsElementDefinitions.leaf. Tactical graphics used in entity-level scenarios.

            • coreTacticalGraphicsElementDefinitions.leaf. Element definitions for tactical graphics that do not have .entity files.

            • AggregateLevelTacticalGraphicsElementDefinitions.leaf. Tactical graphics used in aggregate-level scenarios.

            • baseTacticalGraphicsElementDefinitions.leaf. Tactical graphics used in both entity- level and aggregate level scenarios.


      2. Work Flow Issues for Creating and Editing Element Definitions

        A default VR-Forces installation has multiple element definition files for entities, units, and tactical graphics. When you start VR-Forces they all get loaded. When you open the Visual Model Editors dialog box, all of the element definitions are listed. However, the editor does not keep track of which element definitions come from which element definition file.


        image

        i

        i

        Interaction, spot report, and smoke element definitions are loaded from just one file. They do not have hierarchy and leaf files. You cannot export specific element definitions. When you export them, all definitions get exported to the selected file. Therefore, except for the need to explicitly save all changes, the considerations in this section do not apply to them.


        image


        When you create or edit element definitions, VR-Forces does not automatically save them. Therefore, you are responsible for saving new and edited element definitions to the correct location. This section describes the issues to consider when you work with entity, unit, and tactical graphics element definitions to get the results you want and avoid problems.

        • If you have created new element definitions, the preferred work flow is to export them to a new leaf file. This is the easiest way to avoid overwriting other element definition files and makes them easily portable to newer releases of VR-Forces.

          If you want to add the new element definitions to an existing element definitions file:

          1. Load the hierarchy file. This removes all element definitions.

          2. Load the element definition leaf file you want to edit.

          3. Add the new element definitions.

          4. Export all changes back to the original element definition leaf file.

        • If you have edited existing element definitions, you can export them to their orig- inal leaf file or to a new leaf file:

          • If you export to a new file, make sure that the file name is alphabetically later in alphabetical order than the original element definition file. This ensures that when the new element definition is loaded it will overwrite the original one.

          • If you want to export to the original element definition file, you must plan ahead:

        1. Load the hierarchy file. This removes all element definitions.

        2. Load the element definition leaf file you want to edit.

        3. Make your changes.

        4. Export all changes back to the original element definition file.


        For more information about exporting element definitions, please see “Exporting Element Definitions,” on page 81-35.


        image

        !

        !

        Do not use the Export All Leaves option if you are editing the combined element definition files that get loaded by default unless you are very certain about how you want to use the resultant file. If you export to an existing element definitions file, it will conflict with the other files in that directory.


        image


      3. Creating an Element Definition

        You can create new element definitions. Entity, unit and tactical graphics element defi- nitions get exported to .leaf files. Smoke, spot report, and interaction element defini- tions get exported to .elem files.


        image

        !

        !

        VR-Forces does not save changes to element definitions automatically. If you want to keep changes, you must export them to a file.


        image


        To create an element definition:

        1. If you are adding an entity, unit, or tactical graphic element definition, decide if you want to export the new element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)

        2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        3. Select the page for the type of element definition that you want to create.

        4. If you want to export the new element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)

        5. Expand the element definition hierarchy to the level at which you want to add an element definition and select the parent element (Figure 81-9).



          image

          Figure 81-9. Entity Definition Editor page

          image

        6. Click the Add button ( ). The Create Element Definition dialog box opens.

        7. Type a name for the element definition. (You cannot edit the name after you create it, so try to avoid typing errors.)

        8. Click OK. The new element is added to the list.

        9. Optionally, edit the visual definitions assigned to the element. For details, please see “Editing a Visual Definition,” on page 81-27.

        10. Optionally, add a visual definition to the element. For details, please see “Adding a Visual Definition,” on page 81-26.

        11. Export the element definition. If you made any changes to an entity, unit, or tactical graphics hierarchy, you must export the hierarchy also. (For details, please see “Exporting Element Definitions,” on page 81-35.)


      4. Editing an Element Definition

        An element definition consists of a list of visual definitions for that element. You can add visual definitions and you can edit their parameters. In most cases, you cannot delete an inherited visual definition.


        image

        !

        !

        VR-Forces does not save changes to element definitions automatically. If you want to keep changes, you must export them to a file.


        image


        Adding a Visual Definition

        To add a visual definition to an element definition:

        1. If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)

        2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        3. If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)

        4. Select the page for the type of element definition that you want to edit (Figure 81-9).

        5. Select the element definition that you want to edit.

        6. Optionally, on the Model Sets list, select the model set you want to use.

          image

        7. Click the Add button ( ) next to the Visual Definitions label. The Create Visual- izer Definition dialog box displays a list of available visual definitions.


          image

          Figure 81-10. Create Visualizer Definition dialog box

        8. Select the visual definition that you want to add.

        9. Click OK. The visual definition is added to the element.

        10. Optionally, edit the parameters for the visual definition. For details, please see “Editing a Visual Definition,” on page 81-27.

        11. When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)


          Editing a Visual Definition

          Visual definitions and their attributes are displayed either as gray italicized text or as black text (Figure 81-11). Italicized text indicates that the visual definition or attribute is inherited from a parent element. Visual definitions and attributes that are not itali- cized are particular to that element. (These entries could be inherited by child elements.)


          image

          Figure 81-11. Visual definition entry

          To edit a visual definition parameter:

          1. If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)

          2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

          3. Select the page for the type of element definition that you want to edit (Figure 81-9).

          4. If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)

          5. Select the element definition that you want to edit.

          6. In the Visual Definitions pane, click the value of the attribute that you want to edit. Depending on the attribute, a list of available values is displayed, a dialog box is displayed (Figure 81-12), or the field becomes editable.


            image

            Figure 81-12. Choose Model Definitions dialog box

          7. For a list, select the new value. For an editable field, type a new value. For a dialog box:

            image

            1. If the dialog box window does not have a list, click the Add button ( ). A list of values is added to the dialog box window.

            2. Select the value that you want.

            3. Click OK.

          8. When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)


          Mapping to Multiple Model Definitions or Schema

          There may be cases where you want to map a visual definition to multiple model defini- tions or multiple schema. If you do this, VR-Forces randomly assigns the model defini- tion or schema to instances of the object.

          To map a visual definition attribute to multiple values:

          1. If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)

          2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

          3. Select the page for the type of element definition that you want to edit (Figure 81-9).

          4. If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)

          5. Select the element definition that you want to edit.

          6. In the Visual Definitions pane, click the value of the modeldefinition or modeldefini- tionschema parameter that you want to edit. A dialog box opens. If the attribute already has values, they are listed in the dialog box window as a series of lists (Figure 81-13).


            image

            Figure 81-13. Parameter with multiple values

            image

          7. To add a value, click the Add button ( ). A new list is added to the window.

          8. Select a value from the new list.

            image

          9. To remove a value, click the Delete button ( ) next to the list for that value.


          10. Click OK. The visual definitions list does not show all of the values, but clicking it opens the dialog box again and shows the selected values.

          11. When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)


          Adding an Attribute to a Visual Definition

          Each visual definition has a set of attributes. Some of them may be optional, so they are not specified as part of the factory definitions. You can add optional attributes to a visual definition.

          To add an attribute to a visual definition:

          1. If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)

          2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

          3. Select the page for the type of element definition that you want to edit (Figure 81-9).

          4. If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)

          5. Select the visual definition that you want to edit.

            image

          6. Click the Add Attribute button ( ). The Add Visualizer Definition Attribute window opens. It lists the attributes that are available for the visual definition (Figure 81-14).


            image

            Figure 81-14. Add Visualizer Definition Attribute window


          7. Select the attribute that you want to add.

          8. Click OK. The attribute is added to the visual definition.

          9. Specify a value for the attribute. This might require typing a value, selecting a value from a list, or selecting a value in another window.

          10. When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)


          Deleting an Attribute from a Visual Definition

          You can delete individual attributes from a visual definition.


          image

          !

          !

          The Delete button above the list of visual definitions deletes entire visual definitions. Do not click it thinking it will delete just the selected attribute.


          image


          To delete an attribute:

          1. If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)

          2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

          3. Select the page for the type of element definition that you want to edit (Figure 81-9).

          4. If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)

          5. Select the visual definition that you want to edit.

          6. Select the attribute that you want to delete.

            image

          7. Click the Delete Attribute button ( ).

          8. When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)


      5. Deleting an Element Definition


        image

        !

        !

        VR-Forces does not save changes to element definitions automatically. If you want to keep changes, you must export them to a file.


        image


        image

        i You cannot delete an element definition if it is being used.

        image

        To delete an element definition:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the page for the type of element definition that you want to delete (Figure 81-9).

        3. If you are deleting an entity, unit, or tactical graphic element definition, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)

        4. Select the element definition that you want to delete.

          image

        5. Click the Delete button ( ) next to the Entity Definitions label.

        6. Confirm the deletion.

        7. Export the element definition back to the original element definition file. (For details, please see “Exporting Element Definitions,” on page 81-35.)


      6. Saving Element Definitions

        Changes to element definitions do not get saved automatically. You must explicitly export the changes to a file. For details, please see “Exporting Element Definitions,” on page 81-35.


      7. Importing Element Definitions

        You can import element definitions and replace the loaded element definitions. You can import element definitions and merge them with the loaded element definitions.

        If you want to import entity, unit, or tactical graphics element definitions, you can import hierarchy files, leaf files, or both. If you import a hierarchy file, it removes all leaf file entries and replaces the previously loaded hierarchy.

        When you import a leaf file, it is merged according to the criteria described in “Managing VR-Forces Settings,” on page 4-21.

        You can also import or merge files in the legacy .elem format. If you import and replace entity, unit, or tactical graphics element definitions using an .elem file, the hierarchy and all element definitions are replaced with those in the elem file. If you merge an

        .elem file, the merge is additive only. Entities with names that already exist are skipped.


        image

        i Interaction, smoke, and spot report element definitions use the .elem format.

        image

        Importing a Hierarchy File

        You can replace the current hierarchy with a different one by importing a hierarchy file or a file in the legacy .elem format.


        image

        i When you import a hierarchy file, all leaf files are removed.

        image

        To import a hierarchy or element definition file and replace the existing definitions:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the page for the type of element definition you want to import.

        3. Click the Import and Replace button image). The Import Element Definitions dialog box opens.

        4. Select the hierarchy file or element definition file (extension .elem or .hier) you want to import.

        5. Click Open.


        Importing and Merging Element Definitions

        You can import and merge element definitions from leaf files or legacy element defini- tion (.elem) files.


        image

        i You cannot import a leaf file unless a hierarchy is already loaded.

        image

        To merge element definitions:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the page for the type of element definition you want to import.

        3. Click the Import and Merge button image). The Merge Element Definitions dialog box opens.

        4. Select the element definition file (extension .elem or .leaf) you want to merge.

        5. Click Open.


          Importing Element Definitions from the Command Line

          You can import and merge entity, unit, and tactical graphics element definitions when you start up VR-Forces using the following command-line options:

        These commands merge element definitions into the default element definitions, which are usually those in ./appData/definitions. You can also specify that the element defini- tions in ./appData/definitions not be loaded. In that case, only those files specified on the command line would get loaded. If none are specified, no element definitions would be loaded.

        To specify that the element definitions in ./appData/definitions not be loaded, start VR- Forces with the --noAppDataEntityDefs, --noAppDataUnitDefs, or

        --noAppDataTacticalGraphicsDefs command-line options.


      8. Exporting Element Definitions

        Smoke, interaction, and spot report element definitions get exported to a file with the extension .elem. Entity, unit, and tactical graphics element definitions, get saved to separate hierarchy (.hier) and leaf (.leaf) files.

        You cannot save portions of the hierarchy. The entire hierarchy gets exported to file.

        When the Visual Model Editors dialog box loads entity, unit, and tactical graphics element definitions it merges several files. When you export all element definitions, they do not get exported back to these files. They get exported to the file you specify. If you keep the new file in the same directory as the installed files, there might be conflicts between them when VR-Forces loads element definitions. The element definition files are sorted into alphabetical order and loaded in that order. In the case of conflicts, the last file loaded wins. Therefore:

        • If you are only adding or editing a few element definitions, save them to one or more new leaf files rather than overwriting one of the default leaf files.

        • When you export to new leaf files, consider carefully how you name them.


        Exporting Element Definitions to .elem Files

        When you export interaction, spot report, or smoke element definitions, all element definitions get exported to one file with the extension .elem.

        To export interaction, spot report, or smoke element definitions:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the page for the type of element definition you want to export.

        3. Click the Export All button image). The Export Element Definitions dialog box opens.

        4. Specify a file to export to.

        5. Click Save.


Exporting Entity, Unit, or Tactical Graphics Element Definitions

If you want to export entity, unit, or tactical graphics element definitions, you must export the hierarchy and leaf information separately. If the hierarchy has not changed, you do not need to export it.

To export a hierarchy file:

  1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

  2. Select the page for the type of element definition you want to export.

  3. Click the Export Hierarchy button image). The Export Element Definitions dialog box opens.

  4. Select the hierarchy file you want to export to or type the name of a new file.

  5. Click Save.

To export all definitions to a leaf file:

  1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

  2. Select the page for the type of element definition you want to export.

  3. Click the Export All Leaves button image). The Export Element Definitions dialog box opens.

  4. Select the leaf file you want to export to or type the name of a new file.

  5. Click Save.

To export selected definitions to a leaf file:

  1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

  2. Select the page for the type of element definition you want to export.

  3. Select the element definitions you want to export.

  4. Click the Export Selected Leaves button image). The Export Element Definitions dialog box opens.

  5. Select the leaf file you want to export to or type the name of a new file.

  6. Click Save.


image

82. Mapping Models and Effects


This chapter explains how to map element definitions to DIS and HLA object types. Chapter F, Model Tutorials walks you through the process of adding a model.

Introduction to Object Type Mapping 82-2

Work Flow Issues for Creating and Editing Object Type Mappings 82-2

Adding an Object Type Mapping 82-4

Editing an Object Type Mapping 82-5

Filtering the Element Definition List 82-7

Deleting an Object Type Mapping 82-7

Saving Simulation Object Type Mappings 82-8

Importing Simulation Object Type Mappings 82-8

Exporting Simulation Object Type Mappings 82-9

Starting without Default Simulation Object Type Mappings 82-9

How VR-Forces Maps DI-Guy Models 82-10

    1. Introduction to Object Type Mapping

      In order to visualize a scene element (entity, unit, detonation, and so on), VR-Forces must map its object type enumeration to an element definition. This section explains how to do that.


      image

      i

      i

      When you add simulation objects and other scene elements in the Simulation Object Editor, it creates model definitions and handles object type mapping. Although this chapter explains all of the details of the Simulation Object Type Mappings dialog box, using the Simulation Object Editor to add simulation objects is the preferred method.


      image


      You map object types to element definitions in the Simulation Object Type Mappings dialog box. It has pages for mapping:

      • Cockpit displays.

      • Detonation effects.

      • Entities.

      • Firing effects.

      • Tactical graphics.

      • Tactical smoke.

      • Units.

        The mapping process is the same for all object types. You can add new object type mappings, edit existing mappings, and delete mappings.


        image

        i

        i

        • You can map more than one element definition to an object type. If you do this, when entities of this type appear in a simulation, VR-Forces randomly assigns one of the element definitions to the entity.

        • You can map an element definition to more than one object type.


image


      1. Work Flow Issues for Creating and Editing Object Type Mappings

        A default VR-Forces installation has multiple object type mapping files. When you start VR-Forces they all get loaded. When you open the Simulation Object Type Mappings dialog box, all of the mappings are listed. However, the dialog box does not keep track of which mappings come from which mapping file. When you create or edit object type mappings, VR-Forces does not automatically save them. Therefore, you are responsible for saving new and edited mappings to the correct location.


        The default model definition files are stored in ./appDate/definitions/<object_- type>/TypeMap, where <object_type> is Aggregate, Detonation, Entity, Fire, Smoke, or Tactical Graphics. Cockpit type mappings are in ./appData/settings/stealth/default_Cock- pitTypeMap.mhtx. Detonation, fire, cockpits, and smoke have one default mappings file. The other object types each have four files, which contain the following types of mappings:

      2. Adding an Object Type Mapping

        This procedure describes how to map an element definition to an object type enumera- tion. The element definition must already exist. The procedure is the same for any page on the Simulation Object Type Mappings dialog box.

        To add an object type mapping:

        1. Decide whether you want to save the new object type mapping to its own file or to an existing object type mapping file, as described in “Work Flow Issues for Creating and Editing Object Type Mappings,” on page 82-2.

        2. Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.

        3. Select the Entity Mapping Settings page (Figure 82-1). The page shows a list of object type enumerations in the Entity Type column. The entity definition mapped to the object type is listed in the Entity Definition column.


          image

          Figure 82-1. Entity Mapping Settings page

        4. If you want to save the new object type mapping to an existing file, use the Import and Replace procedure to load the object type mapping file that you want to save to. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)

          image

        5. Click the Add button ( ). The Create New Entity Type Model Mapping dialog box opens (Figure 82-2). It lists a default object type enumeration.


          image

          Figure 82-2. Create New Entity Type Model Mapping dialog box

        6. In the Entity Type text box, type the enumeration you want to map to a model. (Separate each value with a colon(:).)

        7. In the Entity Definition list, select the entity definition that you want to map to this object type.

        8. Click OK.

        9. The new model mapping is added to the list.

        10. Export the new model mapping to a new or existing file. (For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.)


      3. Editing an Object Type Mapping

        This procedure describes how to edit an object type mapping for a simulation object. The procedure is the same for any page on the Simulation Object Type Mappings dialog box.

        To edit an object type mapping:

        1. Decide whether you want to save the edited object type mapping to its own file or to an existing object type mapping file, as described in “Work Flow Issues for Creating and Editing Object Type Mappings,” on page 82-2

        2. Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.

        3. Select the Entity Mapping Settings page (Figure 82-1).

        4. If you want to save the edited object type mapping to an existing file, use the Import and Replace procedure to load the object type mapping file that you want to save to. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)

          image

        5. Select the model mapping that you want to edit. If you know the entity enumera- tion that you want to edit, you can type the enumeration in the Entity Type text box and click the Search button ( ). VR-Forces highlights the entry for that enumeration, if it is present.


        6. To change the enumeration associated with an element definition:

          1. In the Entity Type column, click the enumeration to make it editable.

          2. Change the values of the enumeration.

          3. Click someplace else in the window.

        7. To change the element definition associated with an enumeration:

          1. Optionally, filter the list of available element definitions. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

          2. In the Entity Definition column, click the element definition to make it an editable list (Figure 82-3).

          3. Select the new element definition from the list.

          4. Click someplace else in the window.


            image

            Figure 82-3. Editable entity definition

        8. Export the model mapping to a new or existing file. (For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.)


      4. Filtering the Element Definition List

        You can filter the list of element definitions that are available in the Entity Definition (Figure 82-3) list for mapping to entity types.


        image

        i

        i

        Filtering does not change the list of simulation objects in the Entity Mapping Settings window. It just changes the list of simulation objects in the Entity Definition list when you change a specific mapping.


        image


        To filter the list of element definitions:

        1. On any page of the Simulation Object Type Mappings dialog box, click the Filter button image). A menu is displayed. A check mark indicates the type of element defi- nition that will be displayed when you make a element definition entry editable. (You may have to expand the hierarchy to see which elements are checked.)

        2. Select the element definition type that you want to see in the list or select All to see all element definitions.


      5. Deleting an Object Type Mapping

        The procedure for deleting an object type mapping is the same for any page on the Simulation Object Type Mappings dialog box.

        To delete an object type mapping:

        1. Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.

        2. Select the Entity Mapping Settings page (Figure 82-1).

        3. Use the Import and Replace procedure to load the object type mapping file that you want to delete a mapping from. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)

          image

        4. Select the model mapping that you want to delete. If you know the entity enumer- ation that you want to edit, you can type the enumeration in the Entity Type text box and click the Search button ( ). VR-Forces highlights the entry for that enumeration if it is present.

          image

        5. Click the Delete button ( ).

        6. Export the model mapping to the file you imported. (For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.)


      6. Saving Simulation Object Type Mappings

        New and changed simulation object type mappings do not get saved automatically. You must export them to the appropriate file. For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.


      7. Importing Simulation Object Type Mappings

        You can import simulation object type mapping files. An imported file replaces or merges with the previously loaded mappings.


        image

        !

        !

        When you merge type mappings, mappings from the file being merged in overwrite matching mappings that have already been loaded. If you have multiple models mapped to an object enumeration, all of the mappings are replaced by the new mappings.


        image


        To import simulation object type mappings:

        1. Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.

        2. Select the page for the type of simulation object whose mappings you want to import.

        3. To replace the current set of mappings, click the Import and Replace button image). The Import Mapping Settings dialog box opens.

          image

          To merge mappings, click the Import and Merge button ( ). The Merge Mapping Settings dialog box opens.

        4. Select the settings file you want to import.

        5. Click Open.


      8. Exporting Simulation Object Type Mappings

        You must export all changes to simulation object type mappings. You can export all mappings to a file or you can select specific mappings and export them.


        image

        !

        !

        If you have not explicitly loaded and replaced the list of object type mappings, do not export them to an existing file. The existing file will be replaced either by all of the mappings loaded in the Simulation Object Type Mappings dialog box or by the selected object type mappings.


        image


        To export all simulation object type mappings to one file:

        1. Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.

        2. Select the page for the type of simulation object whose mappings you want to export.

        3. Click the Export All button image). The Export Mapping Settings dialog box opens.

        4. Specify the file to export to.

        5. Click Save.

        To export selected object type mappings to a file:

        1. Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.

        2. Select the page for the type of simulation object whose mappings you want to export.

        3. Click the Export Selected button image). The Export Mapping Settings dialog box opens.

        4. Specify the file to export to.

        5. Click Save.


      9. Starting without Default Simulation Object Type Mappings

        When you start VR-Forces, you can specify that it not load the entity, unit, or tactical graphics type mappings in ./appData/definitions or ./appData/settings/<application>. To do this, start VR-Forces with the --noAppDataEntityTypeMap,

        --noAppDataEntityTypeMap, or --noAppDataEntityTypeMap command- line option.


      10. How VR-Forces Maps DI-Guy Models

Ordinarily, VR-Forces chooses animations to play for a DI-Guy based on the lifeform’s speed, position, and similar attributes. However, VR-Forces can specify the DI-Guy state and appearance with the Set DI-Guy Appearance set data request and the Set DI- Guy Animation task. Once you explicitly set the DI-Guy appearance or animation, VR-Forces no longer tries to choose animations and expects to be told how to render that lifeform for the remainder of the simulation.


image

83. 2D Icons, Cockpits, Wakes and other Visual Models

Chapter 81, Model and Element Definitions provides a general introduction to model schemas, model definitions, and element definitions. This chapter describes how to configure several specific types of visual models.

Configuring 2D Icons 83-2

Editing Font-Based 2D Icons 83-2

Using Images for 2D Icons 83-4

Adding Images for Simulation Object Icons 83-9

Adding New Cockpit Display Models 83-10

Installing a Cockpit DLL 83-11

Creating a Model Definition for a Cockpit 83-11

Adding Object Models as Props 83-13

Adding a Category to the Props Palette 83-14

Configuring Wakes 83-14

Configuring Tidal Stream Wakes 83-17

Adding Wind-based Controls to Models 83-18

Using Texture Atlases to Skin Models 83-19

Configuring Texture Mapping in the Model Definition 83-19

Metafiles for Texture Mapping 83-20

Flipping DDS Textures for a Model 83-21

Configuring SpeedTree Trees 83-22

Randomizing the Size of SpeedTrees 83-24

Best Practices for Creating Models for VR-Forces 83-26

Compressing Model Files 83-27

    1. Configuring 2D Icons

      The 2D icons in VR-Forces are configured in visual definitions. Font-based icons are configured in the Military Symbol Icon visual definition. Image-based icons use the Entity Image Symbol visual definition.


      image

      i

      i

      You can quickly change the 2D icon for a simulation object in the Simulation Object Editor. For details, please see “Editing a Simulation Object’s Visual Model,” on page 65-19.


      image


      1. Editing Font-Based 2D Icons

        By default, 2D icons are configured in the Military Symbol Icon visual definition, which is part of a simulation object’s entity definition. This visual definition uses font- based icons. You can change a simulation object’s icon by changing the fillGlyph and outlineGlyph attributes.

        To change a simulation object’s icon:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Entity Definition Editor page (Figure 83-1).

        3. Select the simulation object whose icon you want to edit.

        4. In the Model Sets list, select 2D Icons.

        5. To change the fill glyph:

          1. Under the Military Symbology Icon visual definition, select the fillGlyph attri- bute (Figure 83-1).



            image

            Figure 83-1. Military Symbol Icon visual definition

          2. Click the value in the Value column. The Choose Font Glyph dialog box opens (Figure 83-2).


            image

            Figure 83-2. Choose Font Glyph dialog box

          3. Select the glyph with the fill pattern you want to use. Click OK.

        6. To change the outline glyph, follow the same procedure as changing the fill glyph.


      2. Using Images for 2D Icons

        By default, VR-Forces uses TrueType fonts for 2D icons. You can replace the font-based icons with images using the Entity Image Symbol visual definition.


        image

        i

        i

        If you configure images for icons, be sure to save the element definitions to a file other than the default settings. If you revert to factory defaults or otherwise switch back to font-based icons and you have not saved the image mappings, you will not be able to recover them without repeating the entire mapping process again.


        image


        To use images for entity icons:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Entity Definition Editor page (Figure 83-1). (If you want to change the icon for a unit, select the Unit Definition Editor page. To change the icon for a waypoint, select the Tactical Graphics page.)

        3. In the Model Sets list, select 2D Icons.

        4. In the Element Definitions list, select Entity. (If you are editing unit images, in the Element Definitions list select Aggregate. If you are editing tactical graphics images, in the Element Definitions list select Waypoint. For all other tactical graphics, skip to step 8.)

        5. In the Visual Definitions list, select Military Symbology Icon (Figure 83-3).


          image

          Figure 83-3. Entity element definition with Military Symbology Icon visual definition

          image

        6. Click the Delete button ( ). The visual definition gets deleted.


          image

        7. Click the Add button ( ). The Create Visualizer Definition window opens. It displays a list of visual definitions (Figure 83-4).


          image

          Figure 83-4. Create Visualizer Definition window

        8. Select Entity Image Symbol. (If you are configuring images for units, select Aggre- gate Image Symbol; for tactical graphics, select Tactical Graphic Image Symbol.)

        9. Click OK.

        10. In the Visual Definitions list, select Entity Image Symbol (Figure 83-5).


          image

          Figure 83-5. Entity element definition with Entity Image Symbol visual definition

          image

        11. Click the Add Attribute button ( ). The Add Visualizer Definition Attribute window is displayed (Figure 83-6).



          image

          Figure 83-6. Add Visualizer Definition Attribute window

        12. In the attribute list, select parent.

        13. Click OK. The parent attribute is added to the visual definition.

        14. Click the value field to make it editable.

        15. Type Main Model and press Enter.

        16. Click the Add Attribute button.

        17. In the attribute list, select type. The value is filled in automatically.

        18. Click the Add Attribute button.

        19. In the attribute list, select modeldefinitionschema. The Choose Supported Model Definition Schema dialog box opens (Figure 83-7).


          image

          Figure 83-7. Choose Supported Model Definition Schema dialog box

        20. Click the Add button. A list is added to the dialog box.

        21. In the list, select WidgetTheme (Figure 83-8).



          image


          Figure 83-8. Completed Choose Supported Model Definition Schema dialog box

        22. Click OK.

        23. Click the Add Attribute button.

        24. In the attribute list, select imagesymbolmap. The 2D Symbol Image Mapper dialog box opens (Figure 83-9).


          image

          Figure 83-9. 2D Symbol Image Mapper dialog box

        25. Click the Add button. A list is added to the dialog box. It lists the forces for which you can map images. and the images that you can apply to a particular force

        26. Select a force and an image from the lists (Figure 83-10).


          image

          Figure 83-10. 2D Symbol Image Mapper dialog box with force chosen

        27. Add an entry for each force that you want to represent with an image.

        28. Click OK.

        29. Click the Add Attribute button.

        30. In the attribute list, select destroyedsymbol. The destroyedsymbol attribute is added to the visual definition.

        31. In the destroyedsymbol list, select Destroyed. The completed visual definition should look similar to Figure 83-11.


          image

          Figure 83-11. Entity Image Symbol visual definition


          The settings for the Entity Image Symbol visual definition are inherited by each entity in the hierarchy from the base Entity definition. Unless you configure the various entity categories, all entities use the images you configured for the Entity category. Therefore, at a minimum, change the imagesymbolmap values for each force at each generic object type, such as Fixed Wing and Life Form, to use the proper image for that object type. Optionally, you can specify an image for each entity definition at the leaf level.


          image

          i

          i

          When you edit the Entity Image Symbol visual definition attributes, be sure that you select the 2D Icons model set.


          image


      3. Adding Images for Simulation Object Icons

        VR-Forces includes a representative set of MIL-STD 2525a images. They are in

        ./data/images. If you want to add your own images, you can do so by adding a new model definition or changing the image mapping for an existing model definition. The new images are automatically added to the list of images for the imagesymbolmap in the Entity Image Symbol visual definition.

        To add images for entities:

        1. Copy the new images to ./data/images.

        2. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        3. Select the Model Definition Editor page (Figure 81-4).

        4. In the Schema list, select WidgetTheme.

        5. If you want to change the image used for an existing model definition:

          1. Select the model definition that you want to change, for example, 2525a_groundF.

          2. Change the file specified for the backgroundImage attribute. If you want to specify an image for a new model definition:

            1. Create a new model definition, as described in “Creating and Editing Model Definitions,” on page 81-9. It is recommended that you copy an existing model definition for a 2525a symbol.

            2. Specify the image that you want to use for the new model definition.


    2. Adding New Cockpit Display Models

      VR-Forces supports cockpit displays created with GL Studio. A cockpit is implemented through a Reusable Software Object (RSO) DLL. A cockpit's values are changed through updaters. An updater is associated with a cockpit attribute through the cockpit model definition. Figure 83-12 shows the model definition for a cockpit.

      Cockpit updaters are associated with an attribute name that is known to the RSO. The value you provide for a cockpit-specific attribute is the name of an updater for dynami- cally changing values or a constant value. Constant values are commonly used to configure a cockpit when it is loaded. VR-Forces provides a set of commonly used updaters. You can add additional updaters or override existing updaters through a plug- in.


      image

      i

      i

      The GL Studio license included with VR-Forces only covers the cockpits delivered with the product. If you add your own cockpits, you will need GL Studio run-time licenses.


      image



      image

      Figure 83-12. Cockpit model definition

      The general procedure for adding a new cockpit model is:

      1. Install the cockpit’s DLL.

      2. Create a model definition for the cockpit.

      3. Map object types to the model definition, as described in “Adding an Object Type Mapping,” on page 82-4.

      2D Icons, Cockpits, Wakes and other Visual Models — Adding New Cockpit Display Models

      image

      1. Installing a Cockpit DLL

        If you create your own cockpit, it is implemented as an RSO DLL that you must add to the VR-Forces file structure.

        To install a new cockpit, place the DLL for the cockpit in ./data/Huds and create a model definition for it.


      2. Creating a Model Definition for a Cockpit

        Cockpit models are configured using schemas and model definitions, just like any other model in VR-Forces. This section provides additional details specific to cockpits.

        To create a model definition for a cockpit:

        1. Add a new model definition, as described in “Creating a Model Definition,” on page 81-12. Be sure to select Cockpit Display as the schema. A new model defini- tion is added to the display (Figure 83-13). The message window lists the parame- ters that you must add. These are the parameters defined by the schema.



          image

          Figure 83-13. New cockpit model definition

        2. Add the required parameters, as described in “Adding Parameters to a Model Defi- nition,” on page 81-15. Table 83-1 describes the required parameters.

          image

          Table 83-1: Required parameters for cockpit models


          Parameter Description

          Parameter Description

          Filename The name of the DLL without the file extension.

          RSOName The name of the class to be loaded from the DLL. Default: filenameClass.

          Perspective 2D or 3D. This parameter refers to the perspective of the cockpit display, not the terrain.

          image


          image

          Table 83-1: Required parameters for cockpit models


          Parameter Description

          Parameter Description

          PerspectiveWidth PerspectiveHeight

          Adjusts the orthogonal projection for a 2D cockpit. Adjusts the perspective projection for a true 3D cockpit.

          ChannelKeyword A keyword that tells a channel to display any object that has the keyword in its definition. Default: showCockpits. (This keyword means that any channel that has the showCockpits keyword will show cockpits.)

          image

          image

          image

          Offset X Offset Y Offset Z

          Moves the cockpit offset around the screen. The OffsetX value shifts the cockpit left or right. The OffsetY value shifts it up or down. OffsetZ shifts a 3D cockpit forward and back. It has no effect on 2D cockpits.


          image


        3. Add the parameters required by the cockpit RSO. To do this, add an Attribute parameter, as follows:

          1. Add an Attribute parameter, as described in “Adding Parameters to a Model Definition,” on page 81-15.

          2. Double-click the parameter to make its name editable.

          3. Add a colon and the name of an RSO attribute that you need to map. For example, Attribute:Heading.

          4. In the Value column, click the value to make it editable. Type the name of an updater or specify a constant value in the format Value:value. You can specify an updater that you have added through a plug-in or one of the updaters provided with VR-Forces, as described in Table 83-2.

        4. Map an object type to your definition, as described in “Adding an Object Type Mapping,” on page 82-4.

          image

          Table 83-2: Updaters provided


          Updater Description

          Updater Description

          AOA Angle of Attack. Returns the pitch of the entity clamped (5 to 30 degrees).

          FeetAGL Feet Above Ground Level. Returns the feet above the terrain (or buildings below).

          FeetMSL Feet Above Mean Sea Level. Returns the altitude above the sea level.

          FeetPerMinute Feet Per Minute. Returns the climb rate. KilometersPerHour Speed of the entity in kilometers per hour. MilesPerHour Speed of the entity in miles per hour.

          KnotsPerHour Speed of the entity in nautical miles per hour.

          Pitch Returns the pitch of the entity clamped (-180 to 180 degrees).

          image

          2D Icons, Cockpits, Wakes and other Visual Models — Adding Object Models as Props

          image


          image

          Table 83-2: Updaters provided


          Updater Description

          Updater Description

          Roll Returns the roll of the entity clamped (-180 to 180 degrees).

          Yaw Returns the yaw of the entity clamped (0 to 360 degrees). Headlight Returns the headlight state of the entity as true or false.

          Value This updater sends any value to the cockpit once and then never again. It is used to configure initial setup and to turn display components on or off.

          image


    3. Adding Object Models as Props

Props are terrain objects that you can select independently of the terrain. “Extracting Props from a Terrain Patch,” on page 55-20 explains how to create them by extracting them from a terrain or a feature layer. You can also add props by creating model defini- tions for them. These props are added to the Props Palette and are then available to add to a terrain.

To add an object model as a prop:

  1. Add a new model definition, as described in “Creating and Editing Model Defini- tions,” on page 81-9. Use the Entity, Tree, or SpeedTree schema, as appropriate. When you name the model definition, if you preface it with one of the categories on the Props Palette, such as Buildings, it automatically is placed in that category on the palette. For example, BuildingsMyBuilding puts MyBuilding in the Build- ings category.

  2. Add the filename parameter.

  3. Set the value for the filename to the location of your object model file. You can select any supported format. (Some formats, such as Collada (DAE) are not included in the file filter. To select such a format, choose All Files in the filters list.)


83.3.1. Adding a Category to the Props Palette

The list of categories on the Props Palette is controlled by the configuration file

./appData/settings/vrfGui/VRF3DTerrainPropCategories.xml. To add a new category, edit the file. The format should be obvious from examining the existing XML elements.


image

i

i

If you edit VRF3DTerrainPropCategories.xml, be sure to update the <count> element to reflect additions or deletions.


image


    1. Configuring Wakes

      When dynamic ocean is enabled, VR-Forces simulates wakes on surface entities. Wakes are configured in the Ship Wake visual definition of an entity’s element definition. If you add your own model, you may want to change the default configuration values for its wake so that it more closely matches the dimensions and velocity of the object type being modeled.


      image

      i

      i

      You can also configure wakes in the Simulation Object Editor. For details, please see “Configuring Wakes,” on page 65-41.


      image


      To configure a ship wake in the Visual Model Editors dialog box:

      1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

      2. Select the Entity Definition Editor page (Figure 83-14).


        image


        Figure 83-14. Ship Wake visual definition

      3. In the Element Hierarchy, expand the Entity list to the Surface level and select the entity that you want to configure.

      4. In the Visual Definitions list, select and expand the Ship Wake visual definition.

      5. Edit the parameters. Table 83-3 describes each parameter.

        image

        Table 83-3: Ship Wake visual definition attributes


        Parameter Description

        Parameter Description

        beamwidth The width of the ship at its widest point.

        bowsize The size of the bow in world units. This affects the wave- length of the bow wave and the initial spread of spray parti- cles at the bow. Use 0 for a pointy bow.

        bowsprayoffset An offset from the ship position from which to emit spray

        particles.

        bowwaveoffset An offset from the ship position, along the direction of

        travel, at which bow waves will originate.

        bowwavescale A scaling factor for the bow wave's amplitude at the bow

        of the ship.

        draft The depth of the hull underwater.

        hullsprayend The offset from the ship at which hull spray effects end.

        image


        image

        Table 83-3: Ship Wake visual definition attributes


        Parameter Description

        Parameter Description

        hullspraysizescale A scaling factor applied to the hull spray particles.

        hullspraystart The offset from the ship at which hull spray effects begin. hullsprayvelocityscale The initial velocity of hull spray particles as a percent of the

        ship velocity (0-1).

        hullsprayverticaloffset A vertical offset to the starting point of new hull spray

        particles.

        maxbowwave The maximum amplitude of the bow wave, or -1.0 for

        unbounded.

        numhullsprays The number of spray particles emitted periodically along the

        hull of the ship.

        parent The visualizer’s parent.

        propwashenabled Enable or disable propeller backwash effects. propwashoffset An offset from the ship position from which to generate

        propeller backwash effects.

        shiplength A value, that in combination with the entity’s speed, is

        used to determine the length of the bow wake. sprayenabled If enabled, the wake emits spray particles.

        spraysizescale A scaling factor applied to the size of the bow spray parti-

        cles and their random spread.

        sprayvelocityscale A scaling factor for spray effects at the bow of the ship.

        This is applied to the initial velocity of the spray particles. sternwaveoffset An offset for the stern wakes.

        type The type of visualizer.

        wakeoffset An offset to the model’s origin that all other offsets are

        relative to. Changing this offset lets you move all of the wake effects in tandem if the entity model changes.

        image


        83.4.1. Configuring Tidal Stream Wakes

        Tidal stream wakes are supported as stand-alone models and are automatically attached to streamed buoys and beacons. Model definitions for wakes to be used with each of the supported buoy and beacon models are included (BuoysPillarWake, BeaconsLattice- Wake, and so on). You may want to edit them. We recommend wake lengths of at least 20m for best results. (Some of the model definitions specify values less than that.)

        By default, VR-Forces starts with a tidal stream current speed of 0. To see tidal stream wakes, change the speed on the Scene Settings dialog box, Environment Conditions Settings page. For more information, please see “Configuring Marine Conditions,” on page 11-16.

        2D Icons, Cockpits, Wakes and other Visual Models — Adding Wind-based Controls to Models

        image

    2. Adding Wind-based Controls to Models

      VR-Vantage can simulate the movement of flags and windsocks based on the current simulated wind speed and direction on terrains. It can also simulate movement of flags and windsocks on models added through connections or programmatically (this is not supported for props or external references). These features require models with appro- priate switches and articulations, as well as model-specific or terrain-specific metafiles.

      For generic information about the metafile format and syntax, please see section 8.6, Transforming Nodes Programmatically, in VR-Forces Front-End Developers Guide.

      The metafiles for windsocks and flags have sections that configure wind control of nodes, as follows:

      Metafiles used to configure flags and windsocks include .\data\Terrain\Hawaii\Geom- etry\OpenFlightAlaMonana\AlaMoanaGeocentric.meta, .\data\Structures\Poles\Flag- Pole\FlagPoleFlag.meta, and .\data\Structures\Poles\WindSock.meta.

      2D Icons, Cockpits, Wakes and other Visual Models — Using Texture Atlases to Skin Models

      image

    3. Using Texture Atlases to Skin Models

When VR-Forces renders a vehicle model it takes into account information about the geometry of the vehicle, which specifies the dimensions, shape and so on, and textures, which specify the surface characteristics (in other words, how the vehicle looks.) If several models have the exact same geometry, but only differ in how they look (their textures), you can save disk space and some processing time by using the same geometry file for all of the models and a texture atlas to specify the textures to use for each model. (A texture atlas is a composite from multiple textures with the corresponding 3D models having uv coordinates shifted.)

For example, VR-Forces has four different versions of the Airbus 320 jet, one each for American Airlines, British Airways, Lufthansa, and Singapore Airlines. Instead of having four geometry files with associated textures, you can use one geometry file for all four models and reference the appropriate texture in a texture atlas.

Texture skinning requires a MEDF (geometry) file and a texture atlas that has been prepared for the entities that will share the texture atlas. The portions of the texture for a given model are accessed via UV offsets into the texture atlas. This information is stored in a metafile (.meta) that references a .dtxc file. You must also specify the metafile in the model definition for each model that is to use it and a configName parameter that is used to identify the correct texture to use.


      1. Configuring Texture Mapping in the Model Definition

        To use a texture atlas for a model, you must provide values for the metaFileName and

        configName parameters in the model definition.

        To configure texture mapping in a model definition:

        1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

        2. Select the Model Definition Editor page (Figure 81-4).

        3. Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)

        4. Select the model definition that you want to edit.

          image

        5. Click the Add Parameter button ( ). A list of parameters is displayed.

        6. Select metaFileName. The metaFileName parameter is added to the model defini- tion.

        7. In the value column specify the location of the metafile you want to use for this model.

        8. Click the Add Parameter button and select configName. The configName parameter is added to the model definition.

        9. In the value column type a string that VR-Forces should look for in the meta file to identify the texture pattern to use.

          2D Icons, Cockpits, Wakes and other Visual Models — Using Texture Atlases to Skin Models

          image


        10. Export the model definitions.


      2. Metafiles for Texture Mapping

VR-Forces uses metafiles to configure texture skinning. For conceptual information about metafile format and syntax, please see section 8.6, Transforming Nodes Program- matically, in VR-Forces Front-End Developers Guide.

A metafile is associated with a terrain or model in one of the following ways:

The following example shows the meta file for the Airbus 320 jet Airbus320a.meta:

{

"NodeFeatures": [

{

"Linkage": {

"Comment": "Traversal with match up this feature based on NodeName match OR AnnotationName match",

"NodeName": "",

"AnnotationName": "@dis annotation texture"

},

"FeatureData": [

{

"FeatureName": "UvAtlasMapper",

"AtlasFile": "$(DATA_DIR)\\Vehicles\\FixedWing\\Airbus320a\\ Airbus320a.dtxc",

"Mappings": [

{

"ConfigName": "AmericanAirlines", "AtlasKeys": {

"Pattern": "AmericanAirlines"

}

},

{

"ConfigName": "BritishAirways", "AtlasKeys": {

"Pattern": "BritishAirways"

}

},

{

"ConfigName": "Lufthansa", "AtlasKeys": {

"Pattern": "Lufthansa"

}

2D Icons, Cockpits, Wakes and other Visual Models — Flipping DDS Textures for a Model

image


},

{

"ConfigName": "SingaporeAirlines", "AtlasKeys": {

"Pattern": "SingaporeAirlines"

}

}

]

}

]

}

]

}

When VR-Forces loads an Airbus 320, the metaFileName parameter in the model defini- tion points it to the Airbust320a.meta file. The configName parameter in the model defi- nition specifies which texture to use, for example, AmericanAirlines. VR-Forces reads Airbust320a.meta and associates the configName string, with the pattern value, also AmericanAirlines. Then it looks in Airbus320a.dtxc and gets the UV offset of Ameri- canAirlines so it knows which textures to use from the texture atlas.

The UV offsets for these models are configured in Airbus320a.dtxc. (The file contains explanatory comments.)

texture,COLPAT,AmericanAirlines,0.0,0.0 texture,COLPAT,Lufthansa,0.0,0.189612 texture,COLPAT,SingaporeAirlines,0.0,0.344823 texture,COLPAT,BritishAirways,0.0,0.500039


    1. Flipping DDS Textures for a Model

      If a model is displayed upside down because its DDS textures are not what VR-Forces expects, you can specify that the model be flipped. (For more information about DDS textures, please see “Displaying DDS Textures Correctly,” on page 61-10.)

      To flip DDS textures for a model:

      1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

      2. Select the Model Definition Editor page (Figure 81-4).

      3. Optionally, filter the model definitions in the list.

      4. Select the model for which you want to change the DDS parameter.

      5. If the model has the flip DDS textures parameter in its parameters list, set it to 1.

        image

        If the model does not have the flip DDS textures parameter in its parameters list, click the Add Parameter button ( ) to see if this is a valid parameter for this model. If it is, you can add the parameter and set it to 1.

      6. Export the updated setting.


    2. Configuring SpeedTree Trees

      SpeedTree trees are high resolution models of trees. To improve performance, you can set clipping plane and level-of-detail (LOD) values to vary the resolution of the trees placed in the scene based on their distance from the observer. For details about clipping planes, please see “Setting the Clipping Planes,” on page 77-9. Table 83-4 describes the settings you can change.

      image

      Table 83-4: SpeedTree settings


      Parameter Description

      Parameter Description

      Clipping distance The distance at which trees are clipped out of the scene.

      Fade from High LOD to Low LOD The range (near to far) in which high

      LOD trees are gradually replaced with low LOD trees.

      Fade from Low LOD to Billboard The range (near to far) in which low

      LOD trees are gradually replaced with billboard trees. This range is usually greater than the range for high LOD to low LOD.

      Ambient Scalar Multiplies the built-in ambient lighting value in each SpeedTree by the speci- fied amount.

      Diffuse Scalar Multiplies the built-in diffuse lighting value in each SpeedTree by the speci- fied amount.

      Specular Scalar Multiplies the built-in specular lighting value in each SpeedTree by the speci- fied amount.

      image


      To configure SpeedTree trees:

      1. Choose Settings Display. The Display Settings dialog box opens.

      2. Select the SpeedTree Settings page (Figure 83-15).


        image

        Figure 83-15. SpeedTree Settings page

      3. Update parameters as desired.

      4. Click Close.


      1. Randomizing the Size of SpeedTrees

        SpeedTrees can be created as props or streamed into the scene using an earth file. They have a default size. You can configure VR-Forces to scale the size of SpeedTrees by a fixed amount or you can scale them randomly within a specified range. The scale applied to a SpeedTree is the product of several factors.

        If a SpeedTree is a prop, it is scaled as the product of the following settings:

        • The scale attribute in its model definition. If the scale attribute is not part of the model definition, the value defaults to 1.0.

        • A random scale factor as specified on the SpeedTree Randomization page on the Terrain Settings dialog box, if enabled.

        • A feet-to-meters conversion factor of 0.3048.

          If a SpeedTree is a streamed in using an earth file, it is scaled as the product of the following settings:

        • The scale attribute in its model definition. If the scale attribute is not part of the model definition, the value defaults to 1.0.

        • The marker-scale attribute in the model element that configures the trees.

        • A random scale factor as specified on the SpeedTree Randomization page on the Terrain Settings dialog box, if enabled.

        • A feet-to-meters conversion factor of 0.3048.

You can also randomize the orientation of SpeedTrees.


To specify randomization of SpeedTree scaling:

  1. Choose Settings Terrain. The Terrain Settings dialog box opens.

  2. Select the SpeedTree Randomization page (Figure 83-16).


    image

    Figure 83-16. SpeedTree Randomization page

  3. To enable randomization of the SpeedTree scale, select the Enable SpeedTree Scale Randomization check box.

  4. If you enabled Enable SpeedTree Scale Randomization, specify values for the Minimum Tree Scale and Maximum Tree Scale.

  5. To enable randomization of tree orientation, select the Enable SpeedTree Orienta- tion check box.

2D Icons, Cockpits, Wakes and other Visual Models — Best Practices for Creating Models for VR-Forces

    1. Best Practices for Creating Models for VR-Forces

      If you build your own models for use in VR-Forces, following these guidelines will result in models that work efficiently:

      • Keep all textures to powers of two, for example 256x256, 128x512, or 2048x2048:

      • Minimize the number of textures:

        • Create a texture atlas that uses multiple textures combined into one.

        • Group polygons together that use the same texture.

        • Use the same textures for all LOD nodes.

      • Minimize the number of nodes:

        • Keep the hierarchy as flat as possible.

        • Move all LOD nodes to the top of the hierarchy.

        • Minimize unnecessary transforms.

        • When you reuse geometry in the model, use instancing.

      • Minimize the number of polygons that have different attributes:

        • Use the same material on polygons whenever possible.

        • Use two polygons with flipped normals instead of using the double sided attri- bute.

        • Use the same color on polygons whenever possible.

        • Group polygons with similar attributes.

      • Consider using a more aggressive LOD structure:

      • Reduce the number of external references:

        • Merge external reference files.

        • Create instances from external merged reference files.

          2D Icons, Cockpits, Wakes and other Visual Models — Compressing Model Files

          image

    2. Compressing Model Files

The models and image files provided with VR-Forces are shipped in compressed formats (MÄK Encrypted Data Format (MEDF) and MÄK Encrypted Image Format (MEIF)). You may want to compress your models to save space or protect intellectual property. You can convert supported formats to MEDF and MEIF with

./bin64/medfTool.exe. The compression tool supports the 3D modeling formats

supported by VR-Forces, such as OpenFlight, 3DS, and OBJ, and raster formats such as RGB and PNG.


image

i

i

When VR-Forces processes a request to load a a file, such as an external reference in a terrain, it checks the cache and the directory of the requested file for an MEDF version of the file. If it does not exist, it loads the file in the original format.


image


The syntax for medfTool is as follows:

medfTool [-q simple_filename ... -p <integer> -s directory

... -z optimization -i -o -m extensions ...

-x extensions ... --norecurse --directory directory

-f filename -- -v -h]

Table 83-5 describes the arguments.

image

Table 83-5: medfTool arguments


Argument Description

Argument Description

(-- | --ignore_rest) Ignore all arguments after this one.

--directory directory Specifies the directory to search for image and geometry

files to convert into MEDF and MEIF. All subdirectories are visited unless the --norecurse command line option is used.

(-f | --file) filename Convert just this file. The extension of the file must be

specified using -x or -m to indicate it is an image or a geometry file.

(-h | --help) Displays usage information.

(-i | --ignore_errors) Ignore errors in the encryption process and continue

without exiting.

(-m |

--image_exten- sions) extension

Specifies the extensions of image formats which will be converted into MEIF format. Use this argument to encrypt a directory. Can be used multiple times.

--norecurse Do not recurse through subdirectories. Default: recurse

through subdirectories.

(-o | --onlyIfNew) Only generates an encrypted file if the expected output

file does not exist.

image

2D Icons, Cockpits, Wakes and other Visual Models — Compressing Model Files

image


image

Table 83-5: medfTool arguments


Argument Description

Argument Description

(-p | --threads)

threads


(-q | --forceOpaque)

simple_filename


(-s | --search)

directory

Specifies the number of threads to run. Specifying zero results in the number of threads equaling the number of logical processors the host machine has.

Specifies a filename and extension, but no path, to force polygons with these filenames to be opaque. Accepted multiple times.

Adds a directory to the search path when resolving external references. During processing, any external references not found are removed from the generated files. Files in the search path are not converted.

(-v | --version) Display version information and exit.

(-x | --extensions)

extension


(-z | --optimize)

optimization

Specifies the extensions of geometry file formats that will be converted into MEDF format. Use this argument to encrypt a directory. Can be used multiple times.

Specifies the optimization level. Maximum optimization may provide better optimization than the default setting, but it is significantly slower. Possible values are:


image


The following example recursively compresses all FLT, RGB, RGBA, PNG, and DDS files in %MAK_DATADIR%/Terrain:

./bin64/medfTool.exe

--directory %MAK_DATADIR%/Terrain --extensions flt

--image_extensions rgb --image_extensions rgba

--image_extensions png --image_extensions dds

The following example compresses all FLT, RGB, RGBA, PNG, and DDS files in

%MAK_DATADIR%/Lifeforms. It does not compress files in subdirectories.

./bin64/medfTool.exe

--directory %MAK_DATADIR%/Lifeforms --norecurse

--extensions flt --image_extensions rgb

--image_extensions rgba --image_extensions png

--image_extensions dds


image

84. Configuring Emitter Volumes


This chapter explains how to configure display of emitter volumes. For information about how to configure simulation of emitters, please see Chapter 74, Configuring Emitters and Radios.

Configuring Emitter Volumes 84-2

Configuring Emitter Volume Color 84-2

Controlling Emitter Volume Radius 84-3

Configuring Emitter Volume Segments 84-4

    1. Configuring Emitter Volumes

      You can configure how VR-Forces colors emitter volumes, how they are drawn, and how they are scaled for visibility. You can configure emitter volumes by editing the DefaultEllipsoidArc model definition or by creating customized ellipsoid arc model definitions and applying them to different entity models.


      image

      i

      i

      In order for an entity to display emitter volumes in 2D observer modes and 3D observer modes, it must have a 2D Emitter Volume visualizer in its 2D model set and 3D Emitter Volume visualizer in its 3D model sets. The DefaultEllipsoidArc model definition is an attribute of the visualizer.


      image


      1. Configuring Emitter Volume Color

        By default, emitter volumes are displayed using fixed colors for high frequency and low frequency. You can configure emitter volumes to be colored based on the emission frequency or pulse rate. When emitter volume color represents frequency, color is deter- mined by the frequency field of the EM Emission update message. In both cases, you specify a low frequency or pulse rate value and a high value.

        If the emitter frequency or pulse rate is lower than your specified low value, the emitter volume is red. As frequency rises above the specified low value, emitter volume color changes, progressing through the colors of the visible spectrum until the specified high value is reached. At the high value and above, the emitter volume is violet.

        To change coloring from the default, you must add the appropriate attributes to the emitter volume visualizer for the entities whose model definitions you want to change. Table 84-1 describes the emitter volume visualizer attributes that affect emitter volume color.

        image

        Table 84-1: Emitter volume visualizer attributes


        Attribute Description

        Attribute Description

        colorByFrequency If True, color by frequency instead of using static

        colors.

        lowFrequency The low frequency threshold for coloring by frequency.

        Default: 800 MHz.

        highFrequency The high frequency threshold for coloring by frequency.

        Default: 1 GHz.

        usePulseFrequency If colorByFrequency is True and usePulseFrequency is

        True, color emitter volumes by pulse frequency.

        lowPulseFrequency The low pulse rate threshold for coloring by frequency.

        Default: 100 Hz.

        highPulseFrequency The high pulse rate threshold for coloring by frequency.

        Default: 3 KHz.

        image


      2. Controlling Emitter Volume Radius

        A emitter volume’s radius (that is, the distance it extends from the emitter) is based in part on emitter power and in part on elevation and azimuth sweep data obtained from EM-Emission state messages. A higher emitter power value results in a longer radius, while a wider field of view results in a shorter radius (because the radiated power is distributed over a wider area).

        If VR-Forces relied exclusively on these values, the range of sizes among different emitter types could become too wide to be practical, with some emissions being barely visible, and other emissions covering the entire virtual world. Therefore, a configurable exponent weight and scale factor have been added to help fine tune the emitter beam radii. The radius exponent weight (a value between 0 and 1) slows the growth of the radius when power or area is greater than 1 and increases the growth of the radius when power or area is less than 0. The scale factor increases the radii of all beams by the given value.

        To change the scale factor and exponent from the default, you must add one or both of the following attributes to the emitter volume visualizer for the entities whose model definitions you want to change:

        • linearScale. The amount of linear scaling applied to all emitter volumes. Default: 100.

        • exponentialScale. The amount of exponential scaling applied to emitter volumes. Default: 0.1.


          How VR-Forces Calculates the Radius

          VR-Forces calculates emitter volume radius by approximating the spread of the emis- sions based on the elevation and azimuth sweeps. If the approximate coverage is zero, it sets the value to 1. Then it applies the linear and exponential scaling values. The code for implementing this is as follows:

          double tempVar = 8*elevationSweep*sin(2*azimuthSweep); if (tempVar <=0) tempVar=1.0;

          scale = linearScale * pow(sqrt(power/tempVar), exponentialScale );


      3. Configuring Emitter Volume Segments

VR-Forces displays an emitter volume as a group of spherical sections projecting from the sensing device. By default, for each 10 degrees (or portion thereof) in the emitter’s

field of view, VR-Forces draws one segment. Figure 84-1 shows segments set to 10o (the default) and 30o.


image

10o 30o


Figure 84-1. Emitter volume segments

Emitter volume segments are managed by the EllipsoidArc schema and model defini- tions based on it. VR-Forces ships with one ellipsoid arc model definition – DefaultEl- lipsoidArc. You can edit this model definition or create copies of it and customize them. If you want to have different emitter volumes for different entities, assign a different ellipsoid arc model definition to each one.


Specifying the Segment Angle

To specify the segment angle:

  1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

  2. Select the Model Definition Editor page.

  3. Click the Filter button image) and select EllipsoidArc. The ellipsoid arc model defini- tions are listed in the window.

  4. Select DefaultEllipsoidArc (Figure 84-2).


    image

    Figure 84-2. EllipsoidArc model definition

  5. Change the value of the angleSegmentMax parameter. The minimum value is 10 (degrees); the maximum is 45.

  6. Export the updated setting.


Displaying Segment Outlines

By default, VR-Forces displays opaque outlines showing the segment edges along the surface of the emitter volume.



image

Off


On


Figure 84-3. Segment outlines

To display or hide segment outlines:

  1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

  2. Select the Model Definition Editor page.

  3. Click the Filter button image) and select EllipsoidArc. The ellipsoid arc model defini- tions are listed in the window.

  4. Select DefaultEllipsoidArc.

  5. Change the value of the showLines parameter.

  6. Export the updated setting.


    Adding a Custom EllipsoidArc Model Definition

    If you want to customize the segment angle and segment outlines for a particular entity without changing the values for other entities, you must create a separate ellipsoid arc model definition and add it to the entity’s model definition.

    To create a custom ellipsoid arc model definition:

    1. Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.

    2. Select the Model Definition Editor page.

    3. Click the Filter button image) and select EllipsoidArc. The ellipsoid arc model defini- tions are listed in the window.

    4. Select DefaultEllipsoidArc.

      image

    5. Click the Duplicate Model Definition button ( ). The Duplicate Model Defini- tion dialog box opens with a default definition name.

    6. Accept the generated name or type a new name for the model definition.

    7. Click OK. The model definition is added to the list.

    8. Change the parameter values for the new model definition as desired.

    9. Select the Entity Definition Editor page.

    10. Select the entity whose emitter volume you want to change.

    11. Select the 3D Sensor Volume visualizer for the entity.

    12. Click the Value column for the modeldefinition attribute. The Choose Model Defini- tion dialog box opens. It has a list of model definitions.

    13. Select the model definition that you just created.

    14. Click OK.

    15. Export the updated setting.

    16. If you are connected to an exercise, disconnect and then reconnect to enable the new model definition.


image

85. The WRM Specification (DIS Notes)


Some OpenFlight files contain information specified by the WRM Entity Model Specification for DIS Interoperability. This information makes it possible for VR-Forces to depict the state of an entity's articulated and attached parts correctly and to switch among different entity appearances.

This chapter contains information that can help you build entity models that comply with the WRM specification, or add that compliance to existing models.

The WRM specification was developed by MÄK Technologies (now VT MAK), Para- digm Simulation Inc., MultiGen Inc., and SAIC, for the ARPA War Breaker project. (Paradigm Simulation and MultiGen merged and were later acquired by Presagis.)


image

image

i

i

Although the WRM specification was developed for DIS, it is used in the HLA RPR FOM.

Introduction 85-2

The OpenFlight File Format 85-3

Node Name and Comment Fields 85-3

External References and Instancing 85-3

Modeling for DIS Interoperability 85-3

The DIS Attribute Lexicon (DAL) 85-4

DAL Keywords 85-4

Model Coordinate Systems 85-5

Articulated Parts 85-7

Entity Appearances 85-8

Animation 85-11

DIS Keyword Values 85-12

The WRM Specification (DIS Notes) — Introduction

image

    1. Introduction

      In order for visualization applications such as VR-Forces to change the state of a model in response to network messages, they must have certain information about the model. For example, which piece of the model’s geometry is associated with which articulated part, and which piece of a model is associated with a particular entity appearance attri- bute.

      This chapter describes a method of encoding information in an OpenFlight format model so that applications can make these associations. For the most part, information is associated with a MultiGen node by including it as a comment associated with the node. Comments that contain this information begin with the token, @dis.

      VR-Forces depicts the movement of articulated parts and changes in entity appearances only when using models constructed to this specification.

      This chapter represents a subset of the Model Specification for DIS Interoperability (version 001). For more details, please refer to that document. You can obtain the Model Specification at http://www.presagis.com/files/standards/wrm.pdf.

      Although VR-Forces implements only a subset of the functionality enabled by the WRM Model Specification, we recommend that models conform to as much of the specification as is appropriate for the model, to promote compatibility with future versions of VR-Forces, and with visualization applications from other vendors.


    2. The OpenFlight File Format

      The OpenFlight file format organizes geometry into the following types of nodes:

      • Face nodes represent individual polygons.

      • Object nodes represent face nodes that are logically or geographically related. Object nodes can have only face nodes (polygons) as children.

      • Level of detail (LOD) nodes provide a means to select alternate geometries based on a user-definable range. Using lower resolution geometry for objects that are far from the observer saves memory and improves performance.

      • Degree of Freedom (DOF) nodes specify translational or rotational freedom, or both, for portions of a model. They can be used for DIS articulated parts or animated special effects. They specify a type of transformation and its limits, such as “rotate about the x axis between 45 and 135 degrees”. The OpenFlight approach to degrees of freedom is hierarchical.

      • Group nodes represent logically-related or geographically-related object nodes. Group nodes are the most general, and may have any type of nodes, except face nodes, as children.


      1. Node Name and Comment Fields

        Each node contains a comment field for user-definable data. The WRM Specification defines keywords that, when placed in a comment field, provide the information that DIS applications need to properly render a model.


      2. External References and Instancing

        The following OpenFlight constructs provide a means to avoid duplicating massive amounts of geometry:

        • An external reference (or xref) is a pointer to another OpenFlight file that contains additional geometry.

        • A transformation matrix is usually attached to an xref to locate the position and orientation of the referenced object’s coordinate system geometry. Each instance may have a transformation matrix controlling the position and orientation of the child’s coordinate system.


85.3. Modeling for DIS Interoperability

The WRM Specification provides uniform standards for locating and orienting the model coordinate system and a way to map DIS codes to associated models and parts. By conforming to these standards, applications that support the WRM Specification do not need customized software to interpret the multiple potential model formats that might otherwise exist.


      1. The DIS Attribute Lexicon (DAL)

        DIS attributes are specified using the following syntax:

        @dis keyword values # comment

        where:

        • @dis must precede the keyword.

        • keyword is one of the DAL keywords.

        • values can be a number or string. Depending on the requirements of the keyword, the values specified can be an individual value, a comma separated list, or a range.

        • # indicates the start of a comment. Comments are case sensitive. A comment continues until the next @dis entry.

          Remember that all comments will be parsed by VR-Forces, so spelling counts.


      2. DAL Keywords

        The WRM Spec supports the following keywords:

      3. Model Coordinate Systems

        OpenSceneGraph (OSG) and the DIS Standard use different right-hand coordinate systems. Table 85-1 describes the two systems. Figure 85-1 illustrates them.

        Table 85-1: Model coordinate systems


        Coordinate

        OpenSceneGraph

        DIS

        X

        Right

        Forward

        Y

        Forward

        Right

        Z

        Up

        Down


        image

        image

        Z

        X Y

        Y X

        Z


        OSG coordinate system DIS coordinate system

        Figure 85-1. Model coordinate systems

        When you create models, it is recommended that you use the OpenSceneGraph coordi- nate system. The simulation application will convert the coordinates, as follows:

        • xmodel = yDIS.

        • ymodel = xDIS.

        • zmodel = -zDIS.


          Location of the Origin for Models

          The origin of the model’s coordinate system should be located as follows, depending on the domain of the entity:

        • Land: on the base of the vehicle, on the axis of yaw rotation.

        • Surface: On the axis of the center of buoyancy, in the plane of the waterline for unloaded ship.

        • Subsurface: On the axis of the center of buoyancy, in the plane of the waterline for surfaced submarine.

        • Air and Space: At the center of gravity.

Figure 85-2 illustrates the location of a model’s origin for each platform domain.


image

Land

Z


Y

X

On the plane of ground contact, at the axis of yaw rotation.


image

Air Z

Y

X


At the center of gravity.


image

Surface

Z


Y

X

On the axis of the center of buoyancy, in the plane of the waterline for an unloaded ship.


image

Subsurface Z

Y

X


On the axis of the center of buoyancy, in the plane of the waterline of a surfaced submarine.


image

Space Z

Y

X


At the center of gravity.


Figure 85-2. Location of origin by domain


image

    1. Articulated Parts

      The WRM Specification (DIS Notes) — Articulated Parts

      In order for VR-Forces to properly depict the state of articulated parts, models must conform to the following specifications:

      • There must be one DOF node for each articulated part. (This means that if there are several LODs, they should be children of the DOF.) Each articulation DOF should be a descendant of the DOF for the part to which it is attached (unless the parent part is just the base model itself). For example, the DOF for a gun should be a descendant of the DOF for a turret.

      • Each articulated part DOF node must have all of the geometry and other nodes associated with the part underneath it. This DOF node must have a comment asso- ciated with it. The comment must be of the form:

        @dis articulated_part part-number

        where part-number is the enumeration for the particular type of part that this part of the model represents. For example, the part number of a turret is 4096, and the part number of a gun is 4416.

        Therefore, the child group of a turret’s DOF must be commented with:

        @dis articulated_part 4096

        The child group of a gun’s DOF must be commented with:

        @dis articulated_part 4416

      • The WRM Model Specification specifies that information about the legal motions of each articulated part be encoded in the comment field. Currently, VR-Forces does not use this information.

      • Do not include static offsets in the DOF attributes. That is, when you set all of the DOF parameters (X, Y, Z, heading, pitch, roll) to 0, the model should appear in its neutral position.


    2. Entity Appearances

      VR-Forces supports switching between different pieces of a model’s geometry based on appearance attributes. For instance, a tank’s turret should look different if the hatch is open or closed. An entire tank should look different if it is damaged or destroyed.

      Switch nodes are used to represent a choice between several different children, based on a particular appearance attribute.

      We define a switch node as a group node with a comment of the form:

      @dis switch attribute

      where attribute is the name of the attribute that should be used to select a child. (For example, damage, smoke, hatch, and so on.)

      The children of the switch node represent the different portions of a model among which VR-Forces will select, based on the appearance attribute. If a switch node is commented with:

      @dis switch hatch

      it may, for example, have three children containing geometry for a closed hatch, popped hatch, and open hatch.

      These children of the switch node must be commented so that VR-Forces knows which child matches which values of the appearance attribute. The comment is of the form:

      @dis state value-list

      value-list is of the form m[,m]+ where m is one of the following:

      • An integer representing the enumeration of a value that an appearance attribute may take on, for example, 1 for hatch closed.

      • Two integers, a and b, separated by a hyphen, representing all enumerations from a through b, for example, 2-5 for all states whose enumerations are 2, 3, 4, or 5.

      • The integer -1, which indicates that this child is the default child, to be used when the attribute state matches no values in any children.

        For instance, the child of the hatch switch node that represents a closed hatch might be used when the hatch attribute value is either 0 (not-applicable), 1 (closed), or any value other than those enumerated in other children. This child would be commented:

        @dis state 0,1,-1

        The child with the popped hatch geometry should be used when the value is 2 (popped) or 3 (popped with person visible) and is commented:

        @dis state 2,3

        The child that contains the open hatch geometry should be used when the value is 4 (open) or 5 (open with person visible) and is commented:

        @dis state 4,5

        There may be many switch nodes for the same attribute. For example, there may be several pieces of a tank’s geometry that are affected by the destroyed attribute.

        The WRM Specification (DIS Notes) — Entity Appearances

        image


        The WRM Model Specification also discusses the inheritance of appearance attributes from ancestor nodes. VR-Forces does not support this functionality. To tell VR-Forces to, for example, display a camouflaged tank when the paint scheme attribute is set to camouflage, and a normal tank otherwise, you must use the switch node method described previously.

        In Figure 85-3, the turret DOF node is attached to the body Group node. The barrel, gun, and hatch DOF nodes are attached to the turret. This allows the turret to be posi- tioned in the coordinate system of the body, and the barrel, gun, and hatch to be posi- tioned in the coordinate system of the turret.

        This model also contains a switch node that is flagged with animation. The comment on this node is @dis switch moving. This switches between two Group nodes – Stop and Go. Under the Stop node there is a single mesh of the treads of the tank.

        Under the Go node there is a Group node, with the animation flag set on. This creates a flipbook animation of all nodes below this Group node. There are three meshes in different states of moving: Frame 1, Frame 2 and Frame 3. At runtime OpenScene- Graph will animate these meshes when the velocity is not 0.

        If multiple color schemes are needed to represent camouflage, winter, and desert versions, another switch is needed.


        image

        Figure 85-3. 3D model structure


        image

    3. Animation

      The WRM Specification (DIS Notes) — Animation

      By default, animation sequences are displayed as quickly as possible. However, you can configure the animation sequence rate using a WRM animation comment in the animation node's comment field.

      The comment syntax is as follows:

      @dis animation num_frames_per_second [ skip | noskip ]

      where:

      • animation tells VR-Forces that animation instructions follow.

      • num_frames_per_second is the rate at which VR-Forces should display the frames.

      • skip and noskip indicate whether the elapsed time should be used to choose the next frame, or whether at most one frame should be advanced each frame.

        You can also specify how many times to loop through an animation and how long to hold the last frame with the following comments:

      • @dis loopCount count, where count is the number of times to loop through the animation. Default: -1 (loop forever). 0 means do not loop.

      • @dis lastFrameTime time, where time specifies how long, in seconds, to hold the last frame of the animation.

        The loopCount and lastFrameTime comments only work with non-instanced models. You must use them with an animation comment, for example:

        @dis animation 2 skip @dis loopCount 3 @dis lastFrameTime 11.5


    4. DIS Keyword Values

      Table 85-6 through Table 85-11 list the values that you can use for the @dis switch keyword by domain. For any switch keyword, the supported state values (@dis state [value 1],[value 1]...) are listed in the State column. The Bit column lists the appearance bit for setting DIS appearances. (Some bit number are repeated because they are valid only for a particular platform.)


Table 85-2: DIS appearance and states - land domain(Sheet 1 of 3)



Values


Description

State/ Description

Bit

blackout_brake_lights

State of blackout brake

0 = Off

27

lights.

1 = On

blackout_lights

State of blackout lights.

0 = Off

26

1 = On

brake_lights

State of brake lights.

0 = Off

14

1 = On

camouflage_type

Type of camouflage.

0 = Desert

17-18

1 = Winter

2 = Forest

3 = Unused

concealed

Type of concealment.

0 = Not Concealed

19

1 = In Concealed Position

damage

Damaged appearance of

0 = None

3-4

an entity. 1 = Slight

2 = Moderate

3 = Destroyed


Table 85-2: DIS appearance and states - land domain(Sheet 2 of 3)



Values Description

fire_power Characteristics of fire- power kill.

flaming State of flames rising from an entity.

frozen_status Frozen status of an entity.

hatch State of the primary hatch.

State/ Description

image

0 = No

1 = Yes

image

0 = No

1 = Yes

0 = Not Frozen 1 = Frozen

image

0 = Not Applicable 1 = Closed

2 = Popped

Bit


2


15


21


9-11

3 = Popped and Person Visible 4 = Open

5 = Open and Person Visible 6 = Custom1

7 = Custom2

head_lights State of headlights. 0 = No 12

1 = Yes

image

interior_lights State of interior lights. 0 = Off 29

1 = On

launcher State of the platform's primary launcher.

image

masked_cloaked Describes whether or not

the entity is masked or cloaked.

mobility Characteristics of mobility kill.

0 = Not Raised 16

1 = Raised

0 = No 31

1 = Yes

0 = No 1

1 = Yes

image

paint_scheme Paint scheme of an entity. 0 = Uniform 0

1 = Camouflage

power_plant_status State of the entity’s

power-plant.

0 = Off 22

1 = On

image

ramp State of a ramp. 0 = Down 25

1 = Up

smoke State or location of smoke and vapor.

0 = None

1 = Plume

2 = Engine

3 = Engine and Plume

5-6


image


Table 85-2: DIS appearance and states - land domain(Sheet 3 of 3)



Values


Description

State/ Description

Bit

spot_lights

Describes whether spot- lights are on or off.

0 = Off

1 = On

28

tail_lights State of tail lights. 0 = Off 13

image

tent

tent

State of a tent extension. 0 = Not Extended

1 = Extended

State of a tent extension. 0 = Not Extended

1 = Extended

1 = On

trailing_effects Size of the trailing effect

for the entity.


0 = None

1 = Small

2 = Medium

3 = Large


24

24


7-8


image


Table 85-3: DIS appearance and states - air domain(Sheet 1 of 2)



Values


Description

State/ Description

Bit

afterburner

State of an air platform's afterburner.

0 = Off

1 = On

16

anticollision_lights

State of anti-collision lights.

0 = Off

1 = On

14

damage

Damaged appearance of an entity.

0 = None

1 = Slight

2 = Moderate

3 = Destroyed

3-4

flaming

State of flames rising from an entity.

0 = No

1 = Yes

15

formation_lights

State of formation lights.

0 = Off

1 = On

24

frozen_status

Frozen status of an entity.

0 = Not Frozen 1 = Frozen

21

hatch

State of the primary

0 = Not Applicable

9-11

hatch.

1 = Closed

2 = Popped

3 = Popped and Person Visible 4 = Open

5 = Open and Person Visible 6 = Custom1

7 = Custom2


image


Table 85-3: DIS appearance and states - air domain(Sheet 2 of 2)



Values


Description

State/ Description

Bit

interior_lights

State of interior lights.

0 = Off

1 = On

29

landing_lights

State of landing lights.

0 = Off

1 = On

12

lights

State of lights.

0 = Off

1 = On

mobility

Characteristics of mobility kill.

0 = No

1 = Yes

1

navigation_lights

State of navigation lights.

0 = Off

1 = On

13

paint_scheme

Paint scheme of an entity.

0 = Uniform

1 = Camouflage

0

power_plant_status

State of the entity’s power-plant.

0 = Off

1 = On

22

smoke

State or location of smoke and vapor.

0 = None

1 = Plume

2 = Engine

3 = Engine and Plume

5-6

spot_lights

Describes whether spot- lights are on or off.

0 = Off

1 = On

28

trailing_effects

Size of the trailing effect

0 = None

7-8

for the entity.

1 = Small

2 = Medium

3 = Large


image


Table 85-4: DIS appearance and states - surface domain(Sheet 1 of 2)



Values


Description

State/ Description

Bit

damage

Damaged appearance of an entity.

0 = None

1 = Slight

2 = Moderate

3 = Destroyed

3-4

flaming

State of flames rising from an entity.

0 = No

1 = Yes

15

frozen_status

Frozen status of an

0 = Not Frozen

21

entity.

1 = Frozen


Table 85-4: DIS appearance and states - surface domain(Sheet 2 of 2)


Values


Description

State/ Description

Bit

interior_lights

State of interior lights.

0 = Off

1 = On

29

lights

State of lights.

0 = Off

1 = On

mobility

Characteristics of mobility

0 = No

1

kill.

1 = Yes

paint_scheme

Paint scheme of an entity.

0 = Uniform

0

1 = Camouflage

power_plant_status

State of the entity’s

0 = Off

22

power-plant.

1 = On

running_lights

State of running lights.

0 = Off

12

1 = On

smoke

State or location of

0 = None

5-6

smoke and vapor.

1 = Plume

2 = Engine

3 = Engine and Plume

spot_lights

Describes whether spot-

0 = Off

28

lights are on or off.

1 = On

trailing_effects

Size of the trailing effect

0 = None

7-8

for the entity. 1 = Small

2 = Medium

3 = Large


Table 85-5: DIS appearance and states - subsurface domain(Sheet 1 of 2)


Values


Description

State/ Description

Bit

damage

Damaged appearance of

0 = None

3-4

an entity.

1 = Slight

2 = Moderate

3 = Destroyed

flaming

State of flames rising

0 = No

15

from an entity.

1 = Yes

frozen_status

Frozen status of an

0 = Not Frozen

21

entity.

1 = Frozen


image


Table 85-5: DIS appearance and states - subsurface domain(Sheet 2 of 2)



Values


Description

State/ Description

Bit

hatch

State of the primary

0 = Not Applicable

9-11

hatch.

1 = Closed

2 = Popped

3 = Popped and Pers

on Visible

4 = Open

5 = Open and Person Visible

6 = Custom1

7 = Custom2

mobility

Characteristics of mobility kill.

0 = No

1 = Yes

1

paint_scheme

Paint scheme of an entity.

0 = Uniform

1 = Camouflage

0

power_plant_status

State of the entity’s power-plant.

0 = Off

1 = On

22

running_lights

State of running lights.

0 = Off

1 = On

12

smoke

State or location of

0 = None

5-6

smoke and vapor.

1 = Plume

2 = Engine

3 = Engine and Plume


image


Table 85-6: DIS appearance and states - space domain(Sheet 1 of 2)



Values


Description

State/ Description

Bit

damage

Damaged appearance of an entity.

0 = None

1 = Slight

2 = Moderate

3 = Destroyed

3-4

flaming

State of flames rising from an entity.

0 = No

1 = Yes

15

frozen_status

Frozen status of an entity.

0 = Not Frozen 1 = Frozen

21

mobility

Characteristics of mobility kill.

0 = No

1 = Yes

1

paint_scheme

Paint scheme of an entity.

0 = Uniform

1 = Camouflage

0


Table 85-6: DIS appearance and states - space domain(Sheet 2 of 2)



Values


Description

State/ Description

Bit

power_plant_status

State of the entity’s power-plant.

0 = Off

1 = On

22

smoke State or location of smoke and vapor.

0 = None

1 = Plume

2 = Engine

3 = Engine and Plume

5-6


image


Table 85-7: DIS appearance and states - lifeform domain(Sheet 1 of 2)



Values


Description

State/ Description

Bit

camouflage_type

Type

of

camouflage.

0

=

Desert

17-18

1

=

Winter

2

=

Forest

3

=

Unused

compliance Compliance of lifeform. 0 = Lifeform None

1 = Detained

2 = Surrender 3 = Using Fists

4 = Verbal Abuse 1

5 = Verbal Abuse 2

6 = Verbal Abuse 3

7 = Passive Resistance 1

8 = Passive Resistance 2

9 = Passive Resistance 3

10 = Non-Lethal Weapon 1

11 = Non-Lethal Weapon 2

12 = Non-Lethal Weapon 3

13 = Non-Lethal Weapon 4

14 = Non-Lethal Weapon 5

image

15 = Non-Lethal Weapon 6


concealed

Type of concealment.

0 = Not Concealed 19

1 = In Concealed Position

concealed

Type of concealment.

0 = Not Concealed 19

1 = In Concealed Position


damage Damaged appearance of an entity.

0 = None

1 = Slight

2 = Moderate

3 = Destroyed

3-4


image


Table 85-7: DIS appearance and states - lifeform domain(Sheet 2 of 2)



Values


Description

State/ Description

Bit

flashlight

State of lights.

0 = Off

1 = On

frozen_status

Frozen status of an

0 = Not Frozen

21

entity.

1 = Frozen

life_form_state

Lifeform action.

0 = None

1 = Upright Still

2 = Upright Walking

3 = Upright Running

4 = Kneeling

5 = Prone

6 = Crawling

7 = Swimming

8 = Parachuting

9 = Jumping

10 = Sitting

11 = Squatting

12 = Crouching

13 = Wading

14 = Surrender

15 = Detained

paint_scheme

Paint scheme of an entity.

0 = Uniform

0

1 = Camouflage

weapon_1

State of primary weapon.

0 = None

1 = Stowed

2 = Deployed

3 = Firing Position

weapon_2

State of secondary

0 = None

weapon. 1 = Stowed 2 = Deployed

3 = Firing Position


Table 85-8: DIS appearance and states - munition domain



Values


Description

State/ Description

Bit

damage

Damaged appearance of

0 = None

3-4

an entity.

1 = Slight

2 = Moderate

3 = Destroyed

flaming

State of flames rising

0 = No

15

from an entity.

1 = Yes

frozen_status

Frozen status of an

0 = Not Frozen

21

entity.

1 = Frozen

launch_flash

Describes the presence of

0 = No

a guided munitions launch 1 = Yes flash.

masked_cloaked Describes whether or not

image

power_plant_status State of the entity’s

power-plant.

power_plant_status State of the entity’s

power-plant.

the entity is masked or cloaked.

0 = No 31

1 = Yes

smoke State or location of smoke and vapor.


0 = Off

1 = On

0 = Off

1 = On

0 = None

1 = Plume

2 = Engine

image

3 = Engine and Plume


22

22


5-6


trailing_effects

Size of the trailing effect for the entity.

0 = None

1 = Small

2 = Medium

3 = Large

7-8

trailing_effects

Size of the trailing effect for the entity.

0 = None

1 = Small

2 = Medium

3 = Large

7-8


image

Table 85-9: DIS appearance and states - environmental domain


Values

Description

State/ Description

Bit

Values

Description

State/ Description

Bit

density Density of environmental. 0 = Clear 1 = Hazy

2 = Dense

3 = Very Dense 4 = Opaque

5 = Unused

frozen_status Frozen status of an entity.

0 = Not Frozen 21

1 = Frozen

masked_cloaked

image


Table 85-10: DIS appearance and states - cultural feature


image

State/


Bit

Values Description

damage Damaged appearance of an entity.


image

exterior_lights_on Describes whether the

exterior lights are on or off.

flaming State of flames rising from an entity.

image

frozen_status Frozen status of an entity.

Description

0 = None

1 = Slight

2 = Moderate

3 = Destroyed

0 = Off

1 = On


0 = No

1 = Yes

0 = Not Frozen 1 = Frozen


3-4


28


15


21

interior_lights State of interior lights. 0 = Off 29

1 = On

image

internal_heat_on Describes whether the

internal heat is on or off.

masked_cloaked Describes whether or not

image

the entity is masked or cloaked.

0 = Off 22

1 = On

0 = No 31

1 = Yes


smoke

State or location of smoke and vapor.

0 = None 5-6

1 = Plume

2 = Engine

3 = Engine and Plume

smoke

State or location of smoke and vapor.

0 = None 5-6

1 = Plume

2 = Engine

3 = Engine and Plume


Table 85-11: DIS appearance and states - sensor domain(Sheet 1 of 2)



Values


Description

State/ Description

Bit

antenna_raised

Describes whether the antenna is raised or not

0 = Lowered

1 = Raised

16

blackout_lights

State of blackout lights.

0 = Off

1 = On

26

concealed

Type of concealment.

0 = Not Concealed 19

1 = In Concealed Position

camouflage_type

Type of camouflage.

0 = Desert

1 = Winter

2 = Forest

3 = Unused

17-18


Table 85-11: DIS appearance and states - sensor domain(Sheet 2 of 2)



Values


Description

State/ Description

Bit

damage

Damaged appearance of

0 = None

3-4

an entity.

1 = Slight

2 = Moderate

3 = Destroyed

flaming

State of flames rising

0 = No

15

from an entity.

1 = Yes

frozen_status

Frozen status of an

0 = Not Frozen

21

entity.

1 = Frozen

interior_lights

State of interior lights.

0 = Off

29

1 = On

lights

State of lights.

0 = Off

1 = On

mission_killed

Ability to carry out

0 = No

2

mission.

1 = Yes

mobility

Characteristics of mobility

0 = No

1

kill.

1 = Yes

paint_scheme

Paint scheme of an entity.

0 = Uniform

0

1 = Camouflage

power_plant_status

State of the entity’s

0 = Off

22

power-plant.

1 = On

smoke

State or location of

0 = None

5-6

smoke and vapor.

1 = Plume

2 = Engine

3 = Engine and Plume

tent

State of a tent extension.

0 = Not Extended

24

1 = Extended

trailing_effects

Size of the trailing effect

0 = None

7-8

for the entity. 1 = Small

2 = Medium

3 = Large


Table 85-12 lists the supported values for the @dis articulated_part keyword. String values are part of the WRM specification, but are not currently supported.

Table 85-12: DIS Articulations(Sheet 1 of 5)


Value

String

Description

3296

bridge_launcher

Position of the bridge launcher.

3328

bridge_section_1

Position of bridge section 1.

3360

bridge_section_2

Position of bridge section 2.

3392

bridge_section_3

Position of bridge section 3.

7616

fuselage_fold

Fold on plane’s body.

1184

helicopter_main_rotor

Describes main rotor rotation.

1216

helicopter_tail_rotor

Describes tail rotor rotation.

3072

landing_gear

Landing gear on a plane.

3520

launcher_arm_primary

Position of the primary launcher arm.

1120

left_aileron

Position of the left aileron.

1056

left_flap

Position of the left flap.

3168

left_weapon_bay_door

Left door to weapon bay.

3552

other

Position of other articulated parts.

3424

primary_blade_1

Position of the primary blade 1.

3456

primary_blade_2

Position of the primary blade 2.

3488

primary_boom

Position of the primary boom.

5056

primary_defense_systems_1

Position of the primary defense systems 1.

5088

primary_defense_systems_2

Position of the primary defense systems 2.

5120

primary_defense_systems_3

Position of the primary defense systems 3.

5152

primary_defense_systems_4

Position of the primary defense systems 4.

5184

primary_defense_systems_5

Position of the primary defense systems 5.

5216

primary_defense_systems_6

Position of the primary defense systems 6.

5248

primary_defense_systems_7

Position of the primary defense systems 7.

5280

primary_defense_systems_8

Position of the primary defense systems 8.

5312

primary_defense_systems_9

Position of the primary defense systems 9.

5344

primary_defense_systems_10

Position of the primary defense systems 10.

4416

primary_gun_number_1

Position of the primary gun number 1.

4448

primary_gun_number_2

Position of the primary gun number 2.

4480

primary_gun_number_3

Position of the primary gun number 3.

4512

primary_gun_number_4

Position of the primary gun number 4.

image



4544

primary_gun_number_5

Position of the primary gun number 5.

4576

primary_gun_number_6

Position of the primary gun number 6.

4608

primary_gun_number_7

Position of the primary gun number 7.

4640

primary_gun_number_8

Position of the primary gun number 8.

4672

primary_gun_number_9

Position of the primary gun number 9.

4704

primary_gun_number_10

Position of the primary gun number 10.

4736

primary_launcher_1

Position of primary launcher 1.

4768

primary_launcher_2

Position of primary launcher 2.

4800

primary_launcher_3

Position of primary launcher 3.

4832

primary_launcher_4

Position of primary launcher 4.

4864

primary_launcher_5

Position of primary launcher 5.

4896

primary_launcher_6

Position of primary launcher 6.

4928

primary_launcher_7

Position of primary launcher 7.

4960

primary_launcher_8

Position of primary launcher 8.

4992

primary_launcher_9

Position of primary launcher 9.

5024

primary_launcher_10

Position of primary launcher 10.

5376

primary_radar_1

Position of the primary radar 1.

5408

primary_radar_2

Position of the primary radar 2.

5440

primary_radar_3

Position of the primary radar 3.

5472

primary_radar_4

Position of the primary radar 4.

5504

primary_radar_5

Position of the primary radar 5.

5536

primary_radar_6

Position of the primary radar 6.

5568

primary_radar_7

Position of the primary radar 7.

5600

primary_radar_8

Position of the primary radar 8.

5632

primary_radar_9

Position of the primary radar 9.

5664

primary_radar_10

Position of the primary radar 10.

4096

primary_turret_number_1

Position of the primary turret number 1.

4128

primary_turret_number_2

Position of the primary turret number 2.

4160

primary_turret_number_3

Position of the primary turret number 3.

4192

primary_turret_number_4

Position of the primary turret number 4.

4224

primary_turret_number_5

Position of the primary turret number 5.

4256

primary_turret_number_6

Position of the primary turret number 6.

4288

primary_turret_number_7

Position of the primary turret number 7.



4320

primary_turret_number_8

Position

of

the

primary

turret

number

8.

4352

primary_turret_number_9

Position of the primary turret number 9.

4384

primary_turret_number_10

Position of the primary turret number 10.

1152

right_aileron

Position of the right aileron.

1088

right_flap

Position of the right flap.

3200

right_weapon_bay_doors

Right door to the weapon bay.

7584

rotor_fold

Fold on helicopters rotors.

1024

rudder

Position of the rudder.

6656

secondary_defense_sys- tems_1

Position of the secondary defense systems 1.

6688

secondary_defense_sys- tems_2

Position of the secondary defense systems 2.

6720

secondary_defense_sys- tems_3

Position of the secondary defense systems 3.

6752

secondary_defense_sys- tems_4

Position of the secondary defense systems 4.

6784

secondary_defense_sys- tems_5

Position of the secondary defense systems 5.

6816

secondary_defense_sys- tems_6

Position of the secondary defense systems 6.

6848

secondary_defense_sys- tems_7

Position of the secondary defense systems 7.

6880

secondary_defense_sys- tems_8

Position of the secondary defense systems 8.

6912

secondary_defense_sys- tems_9

Position of the secondary defense systems 9.

6944

secondary_defense_sys- tems_10

Position of the secondary defense systems 10.

6016

secondary_gun_number_1

Position of the secondary gun number 1.

6048

secondary_gun_number_2

Position of the secondary gun number 2.

6080

secondary_gun_number_3

Position of the secondary gun number 3.

6112

secondary_gun_number_4

Position of the secondary gun number 4.

6144

secondary_gun_number_5

Position of the secondary gun number 5.

6176

secondary_gun_number_6

Position of the secondary gun number 6.

6208

secondary_gun_number_7

Position of the secondary gun number 7.

6240

secondary_gun_number_8

Position of the secondary gun number 8.


Table 85-12: DIS Articulations(Sheet 4 of 5)


Value

String

Description

6272

secondary_gun_number_9

Position of the secondary gun number 9.

6304

secondary_gun_number_10

Position of the secondary gun number 10.

6336

secondary_launcher_1

Position of the secondary launcher 1.

6400

secondary_launcher_3

Position of the secondary launcher 3.

6432

secondary_launcher_4

Position of the secondary launcher 4.

6464

secondary_launcher_5

Position of the secondary launcher 5.

6496

secondary_launcher_6

Position of the secondary launcher 6.

6528

secondary_launcher_7

Position of the secondary launcher 7.

6560

secondary_launcher_8

Position of the secondary launcher 8.

6592

secondary_launcher_9

Position of the secondary launcher 9.

6624

secondary_launcher_10

Position of the secondary launcher 10.

6368

secondary_launcher_2

Position of the secondary launcher 2.

6976

secondary_radar_1

Position of secondary radar 1.

7008

secondary_radar_2

Position of secondary radar 2.

7040

secondary_radar_3

Position of secondary radar 3.

7072

secondary_radar_4

Position of secondary radar 4.

7104

secondary_radar_5

Position of secondary radar 5.

7136

secondary_radar_6

Position of secondary radar 6.

7168

secondary_radar_7

Position of secondary radar 7.

7200

secondary_radar_8

Position of secondary radar 8.

7232

secondary_radar_9

Position of secondary radar 9.

7264

secondary_radar_10

Position of secondary radar 10.

5696

secondary_turret_number_1

Position of the secondary turret number 1.

5728

secondary_turret_number_2

Position of the secondary turret number 2.

5760

secondary_turret_number_3

Position of the secondary turret number 3.

5792

secondary_turret_number_4

Position of the secondary turret number 4.

5824

secondary_turret_number_5

Position of the secondary turret number 5.

5856

secondary_turret_number_6

Position of the secondary turret number 6.

5888

secondary_turret_number_7

Position of the secondary turret number 7.

5920

secondary_turret_number_8

Position of the secondary turret number 8.

5952

secondary_turret_number_9

Position of the secondary turret number 9.

5984

secondary_turret_number_10

Position of the secondary turret number 10.



3104

tail_hook

Tail hook on a plane for aircraft carrier land- ings.

7584

wing_fold

Fold on plane’s wings.


The appendixes contain supplementary information.



VR-Forces Users Guide

Section XIV - Appendixes


XIV-1



Section XIV - Appendixes

XIV-2 VT MAK


This chapter describes the syntax of VR-Forces MTL files.

Introduction ................................................................................................. A-2 MÄK Technologies Lisp (MTL) Files ........................................................... A-3

Using Environment Variables in an MTL File........................................ A-3

Specifying Lists of Lists .......................................................................... A-4

Using Conditional Statements................................................................ A-4

MTL Syntax — Introduction

image

    1. Introduction

      VR-Forces uses many different configuration files to manage element definitions, model mapping, back-end configurations, menus, and so on. Almost all of the configu- ration files for the front-end are XML files that get created and updated through the Display Settings dialog box, Terrain Settings dialog box, and the other front-end configuration dialog boxes. Although you could edit these files with text editors, we recommend that you not edit them by hand and we do not document their contents and syntax. When you save settings, they are saved to files with the correct extension.


      image

      i

      i

      Developers may need to create and edit configuration files using the VR- Forces Front-End API. Please see VR-Forces Front-End Developers Guide and the class documentation for details.


      image


      The back-end configuration files mostly use the MÄK Technologies LISP (MTL) syntax. The major back-end configuration file is vrfSim.mtl. It is described in Appendix A, MTL Syntax. Other files are described throughout this manual in the appropriate section.

      MTL Syntax — MÄK Technologies Lisp (MTL) Files

      image

    2. MÄK Technologies Lisp (MTL) Files

      Many of the configuration files for MAK products are ASCII text files that use MÄK Technologies LISP (MTL) to encode configuration information. MTL files have the extension .mtl. You can edit them in any text editor. Be sure that your text editor uses the proper end-of-line characters for your platform.

      Most parameter entries take the format:

      (setq parameter_name value)

      For example:

      (setq EnableWireFrame 1)

      Or:

      (setqb parameter_name value)

      The setqb syntax indicates a bound variable.

      To comment out a line, precede the text with two semi-colons (;;). You can also add a comment at the end of a line by preceding it with two semi-colons.

      In most cases, the parameter names are known to the MAK application and the MTL commands simply assign values to them. However, you can use the setq command to create arbitrary symbolic names or aliases that are then used in later commands. For example, in the following two commands, the symbolic name VaporTrail is assigned to an OpenFlight file. Then the symbolic name is used in the trail-map command.

      The name VaporTrail has no intrinsic meaning. It is given meaning by the setq

      command, which allows it to be used later in the trail-map command.

      (setq VaporTrail (list "./../data/models/makTrails/Vapor- Trail" "VaporTrail.flt" 6.0 1.5 1.5 4.0 1.5 0.5))

      (trail-map (list 1 2 -1 0 -1 -1 -1)(list VaporTrail 0.0 0.0

      0.0))

      In addition to the setq command, a commonly used command is the load command. This command instructs the application to load the file specified, for example:

      (load mtl-path "params.mtl")


      1. Using Environment Variables in an MTL File

        If you want to use an environment variable in an MTL file, use the following syntax:

        (setqb parameter_name (getenv (quote env_var)))

        For example:

        (setqb disDestAddr (getenv (quote DEST_ADDR)))

        MTL Syntax — MÄK Technologies Lisp (MTL) Files

        image

      2. Specifying Lists of Lists

        The example of setting a symbolic name in a previous section uses a list. You can also specify a list of lists, for example:

        (trail-map (list 1 2 -1 -1 -1 -1 -1)

        (list vaporTrail -8.0 -3.0 0.0)

        (list vaporTrail -8.0 3.0 0.0)

        )

        A parameter entry can also have multiple individual lists:

        (trail-map (list 1 2 -1 0 -1 -1 -1)(list VaporTrail 0.0 0.0

        0.0))


      3. Using Conditional Statements

MTL commands can be conditional. Conditional statements are used frequently when parameters are different for DIS and HLA. A simple conditional statement has the format:

(if (condition) (statement_to_evaluate))

If you have more than one statement to evaluate, use a sequence block:

;; HLA specific parameters (if (equal HLA 1)

(sequence

(setqb fomMapperLib "") (setqb fomMapperInitData "") (setqb rprFomVersion 1.0)

(setqb pathToSublistFile "sublist.mtl") (setqb ignoreAdvisories 0)

(setqb fedLookahead 1.0)

)

)


image

B. The vrfSim.mtl Configu- ration File


This chapter describes the vrfSim.mtl file.

The vrfSim.mtl Configuration File ............................................................... B-2


    1. The vrfSim.mtl Configuration File

      The file ./appData/settings/vrfSim/vrfSim.mtl configures back-ends. Table B-1 describes the parameters in vrfSim.mtl. The Description column includes the command-line argument equivalent for parameters that have them.


      image

      Table B-1: vrfSim.mtl parameters (Sheet 1 of 7)


      Parameter Description

      Parameter Description

      additionalSystemScriptsDirec- tory

      aggregateSpatialModelTickPeri- odUsesRealTime

      aggregateSpatialModelTickPe- riod

      aggregateSpatialModelTickVari- ance

      aggregateSpatialModelTickAs- FastAsPossibleWhilePaused

      Directories other than the default script directory where VR-Forces should look for system scripts.

      Configure aggregate spatial model tick rates. Default is to run the aggregate spatial model every frame. Tick period is given in seconds, with the special value of -1 indicating tick every frame.

      appNumber Specifies the application number.

      Default: 3001. Command line: -a | -p

      assertOnBlockingTerrainCalls When set to true (1), causes blocking terrain calls to assert

      in debug mode if the simulation is running. Blocking terrain calls can cause long ticks in a running simulation which can have very negative effects on the models. This parameter can help developers find places in the code that are making the offending calls. Note that calling the blocking form of any terrain intersection function causes an assertion; it is not necessary for the call to actually block and even non- paging implementations will assert. This is to make it easier to find potential problems regardless of the particular terrain or location being used. Default: 0. For more infor- mation, please see API documentation.

      batchScenarioFileName Specifies a batch file to run. Command line: -B

      cgfDispatcherReceivePort Specifies the port to be used by the

      DtCgfDispatcher’s file transporter to receive order of battle and plan files from the DtVrfRemoteController.

      countryCodesMappingFile The file VR-Forces uses to import country codes to map to

      object type enumerations.

      daemon Runs vrfSim as a daemon process (Linux only.) vrfSim does not try to read characters from a console, and forks a back- ground process on startup. It exits cleanly on receipt of the SIGTERM, SIGQUIT, SIGINT signals. Default: Off.

      Command line: --daemon

      image



      datumShiftX datumShiftY datumShiftZ


      These parameters, along with the spheroidSemiMajor and spher- oidSemiMinor parameters, let you change the reference ellip- soid used for geocentric to geodetic conversions. For more information, please see Choosing a Reference Ellipsoid in VR-Link Developers Guide. These parameters are used only if VRF_useCustomMapDatum is set to 1.

      defaultParameterDatabasePath Specifies the location to search for the object parameter

      database if the full path is not specified in a scenario file.

      defaultTerrainDatabasePath Specifies the location to search for the terrain database if

      the full path is not specified in a scenario file.

      diGuyAnimationsFile Specifies the DI-Guy animations file to load if useDIGuy is 1.

      disableParallelTick If enabled (1), VR-Forces ticks thread safe components in

      parallel. If disabled (0), all components are ticked serially in the main thread.

      doNotUseConsole Disables (1) or enables (0) writing of output to the console.

      Default: 0.

      enableDebugDrawer Enables (1) or disables (0) the simulation terrain debug

      drawer. Default: 1.

      enableLogFileTimestamps If enabled, puts timestamps in front of each line in for all

      log files.

      enableNavigationLabDebugging Enables debugging using the Navigation Lab application. A

      connection is made on an available port, starting with 4888, to enable Navigation Lab to connect to the simula- tion engine.

      entVrfDataTimeThreshold Specifies how often, in seconds, VR-Forces environmental

      and simulation object data is sent. If you specify -1.0, the update is sent only if some item in the vrfDataObject has changed.

      forceParameterDbReload If set to 1 (default), forces the back-end to reload the

      object parameter database (OPD) each time a scenario is loaded. If set to 0, if a scenario is started that uses the same SMS as the previous one (for example, in a rewind), the SMS is not reloaded.

      frameRateStatisticsLogFile Specifies a log file for frame rate statistics.

      gamewareMemorySize Set the working memory size limit used internally by Game-

      Ware when calculating paths. Size is in MB. Increasing this limit can allow for path plans on larger navigation areas by more entities simultaneously. Note: Multiple working memory blocks are allocated with this limit, so this is not an overall limit for Gameware.

      image


      loadPluginIfVersionMismatch Specifies whether (1) or not (0) to load a plug-in if there is

      a mismatch between how the plug-in was built and how VR-Forces was built. Mismatches can be build type (release versus debug), operating system, or protocol (DIS, HLA 1.3, HLA 1516, HLA Evolved.)

      Allowing a plug-in to load if there is a mismatch can cause VR-Forces to be unstable.

      logFrameRateStatistics Enables (1) or disables (0) logging of frame rate statistics

      to a file.

      maxDrainInputTime Sets the maximum time to wait in drainInput() before

      returning. For the MAK RTI, the default value drains the entire input stream before returning. For the Pitch RTI, the default value reads a single input from the input stream, so set to a value other than -1 to process more information. Use with DIS or HLA.

      msdlSIDCMappingFile The file VR-Forces uses to map between SIDC codes and

      object type enumerations when it imports MSDL files.

      notifyLevel Sets the notification level (0-4) for information and warning messages. Default: 2. Command line: -n

      objectConsoleNotifyLevel Specifies the notification level (0-4) for messages sent to the object console. Default: 1.

      pluginsDirectory Specifies the directory in which configuration (MTL) files

      for plug-ins are located. The directory must end with a slash, for example, ./plugins/

      publishZeroVelocityWhenPaused When set to 1, the default, VR-Forces sets simulation

      object velocities to 0 when it is paused so that simulation objects do not continue to dead reckon. To publish the current velocity, set to 0.

      rejectMismatchedScenarioMes- sages

      reuseEntityIdentifiersOnScenari- oLoad

      If true (the default) reject mismatched scenario run messages based on unique scenario run id.

      If true, reuse object identifiers that might be part of the scenario. If the object identifier saved in the order of battle does not currently match the site/app of the back-end loading that object, then the user will be warned and the object will be assigned a new entity identifier that is compliant with that site/app. This will not apply to simula- tion object groups or scenario import. They will always get new entity identifiers.

      scenarioFileName Specifies the scenario file to load. Command line: -L

      sendBackendLogToNetwork Enables (1) or disables (0) sending simulation engine log

      messages to the front-end.

      sessionId Specifies the session ID. Command line: -i

      image



      setDeadReckoningAlgorithmTo- StaticOnPause


      When the simulation is paused, set the dead reckoning algorithm for aggregates and entities to static. If enabled and publishZeroVelocityWhenPaused is disabled, the objects in a VR-Forces run simulation show current values for velocity, speed, acceleration, and so on.

      setMainThreadToHighPriority If set to 1, sets the main thread to THREAD_PRIORITY_-

      TIME_CRITICAL in Windows. Using this option on a single core processor will probably cause deadlock. (Windows only.)

      simMgmtPduProcessLevel Specifies how simulation management PDUs are

      processed:

      1. – Processes PDUs sent to a specific back-end. Wildcards are ignored.

      2. – Processes only wildcarded PDUs. Ignores those sent to specific back-ends.

      3. – Processes all PDUs.

simulationModelSet Specifies the default simulation model set or sets. If speci-

fying multiple SMSs, separate them by a semi-colon.

siteId Specifies the site ID. 0 = use internal default.

Command line: -s | -t

spheroidSemiMajor spheroidSemiMinor

These parameters, along with the datumShift parameters, let you change the reference ellipsoid used for geocentric to geodetic conversions. For more information, please see Choosing a Reference Ellipsoid in VR-Link Developers Guide. These parameters are used only if VRF_useCustomMap- Datum is set to 1.

startInRunMode Specifies that the simulation start in run mode (1), rather than pause mode (0). Default: 0.

startMinimized If true (1), the back-end minimizes at startup.

statusUpdateHeartbeat Specifies how often, in seconds, the back-end status heart-

beat is sent.

targetFrameRate Specifies the mean frame rate above which the back-end

will sleep, yielding CPU time to other processes. This option applies only to variable frame mode. For more infor- mation, please see “Tuning the Target Frame Rate,” on page 6-17. Default: 22.

image


taskVisualizationPublication- Mode

Specifies whether or not to publish task visualizations and how to publish them, as follows:

0 = Never publish task visualizations.

1 = Standard mode. The VR-Forces GUI will request task visualizations only for objects for which they are enabled.

2 = Always publish task visualizations, regardless of whether they are being displayed in the GUI. Can be useful for logging purposes.

terrainDatabase Specifies the terrain database to load. This parameter is

overridden by the scenario file if one is specified in scenario-

FileName. Command line: -T

useCustomMapDatum Allows modification of the reference ellipsoid used for

geocentric to geodetic conversion. If you enable this parameter, there are several sub-parameters to configure. For details, please see the comments in the file.

useDrawControlForTaskVisual- izations

If true, publish task visualizations as VR-Vantage draw control objects instead of their standard publication method. This allows task visualizations to be displayed in any VR-Vantage based application; however the VR-Forces GUI will no longer be able to filter task visualizations by entity.

image

useDIGuy Specifies whether (1) or not (0) to use DI-Guy characters.


HLA Parameters

For details, please see “Command-line Options for HLA Federations,” on page 5-17

HLA Parameters

For details, please see “Command-line Options for HLA Federations,” on page 5-17

destroyFedExec Specifies whether (1) or not (0) the DtExerciseConn

destructor should try to destroy the federation execution. Default: 1.

execName The federation execution name. Command line: -x

federateName The federate name. Command line: -N

federateType Lets you specify the federate type for HLA Evolved.

fedFileName Specifies the FED file name. Command line: -F

fomMapperLib A FOM Mapper library. Command line: -f

fomMapperInitData An initialization string.

Command line: --fomMapperInitData

hostAddressString Specifies the host address. This is usually the same as the

device address.

localSettingsDesignator Specifies the local settings designator for HLA Evolved.

mimModule Specifies a MIM (MOM and Initialization) Module for HLA Evolved.

minDrainInputTime The minimum time to stay in drainInput() before returning.

image


rprFomVersion The RPR FOM version. (0.5, 0.8, 1.0, 2.0)

Command line: --rprFomVersion

runInTimeManagementMode Enables (1) or disables (0) use of time management.

sendFedTime Enables (1) or disables (0) sending and receipt of interac-

tions in time stamp order. Default: 0.

useAbsoluteTimeStamps If set to 1, use absolute time stamps. If set to 0, use rela-

tive time stamps. Default: 0.

image

useAdvisories Enables (1) or disables (0) HLA advisory messages.


DIS Parameters

Please see “Command-line Options for DIS Exercises,” on page 5-20.

DIS Parameters

Please see “Command-line Options for DIS Exercises,” on page 5-20.

additionalDestinationAddresses Specifies additional destination addresses to send to.

Accepts multiple IP addresses separated by semi-colons (;).

addMulticastAddr The multicast address. Command line: -S

appIdRange Specifies the application ID range to use to identify simula- tion objects generated by VR-Forces.

defaultHeartbeatThreshold Specifies the DIS heartbeat threshold, in seconds. A heart-

beat is sent when the threshold is reached, even if no data has changed.

defaultObjectTimeout Specifies the DIS object timeout threshold, in seconds. If

VR-Forces does not receive a heartbeat for an object for the time period specified, it removes the object from the exercise.

destAddrString Destination address for point-to-point communications

mode. Command line: -A

deviceAddress Specifies the address of the network card to use for UDP

traffic.

disPort The port number. Command line: -P

exerciseId The exercise ID. Command line: -x

heartbeatVariance When a simulation object is created, a random value

between -heartbeatVariance and +heartbeatVariance is added to the heartbeat. This spreads heartbeats over time instead of them all being at the same time.

hostAddressString Specifies the host address. This is usually the same as the

device address.

maxDrainInputReads The maximum number of reads to make in drain input

before returning

mcastTtl Specifies the multicast time to live.

Command line: --mcastTtl

image



recvBufferSize Specifies the receive buffer size, as a positive value. A

value of -1 means use the system default.

Command line: --recvBufferSize

sendBufferSize Specifies the send buffer size, as a positive value. A value

of -1 means use the system default.

Command line: --sendBufferSize

subnetMask When the destination address is not specified (“0.0.0.0”), the subnet mask is used in conjunction with the network interface address to determine the destination broadcast address. If neither is specified (subnet mask is blank), the network interface's default broadcast address is used.

suppressSelfReflect Prevent VR-Forces from reflecting DIS PDUs.

useAbsoluteTimeStamps If set to 1, use absolute time stamps. If set to 0, use rela-

tive time stamps. Default: 0.

useAsyncIO Enables (1) or disables (0) use of asynchronous I/O, which can help reduce dropped packets under heavy network load. Default: 0. Command line: -I

useIpv6 Use the IPV6 protocol.

image


image C. Object Parameters


This appendix describes the high-level parameters in the object parameter database. The OPD Editor has context-sensitive help for most parameters and also describes them in the online help system. It also has reference material for local and remote subcomponents and object type enumerations.

The Structure of a Simulation Object Parameter.......................................... C-2 The Parameter Type Hierarchy.................................................................... C-3

Vrf Base Object Parameters ................................................................... C-3

Vrf Object Parameters........................................................................... C-7

Moving Object Parameters.................................................................... C-8

Parameter Types for Entity Platforms.................................................... C-8

Simulation Object Parameters...................................................................... C-8

Object Type Enumerations.......................................................................... C-9

Object Super-type ................................................................................. C-9

AggregateKind....................................................................................... C-9

ObjectKind ......................................................................................... C-10

Unit Category ..................................................................................... C-10

Unit Specific ....................................................................................... C-11

Point Object Category......................................................................... C-12

Linear Object Category ....................................................................... C-12

Areal Object Category ......................................................................... C-12

Interaction........................................................................................... C-12

Object Parameters — The Structure of a Simulation Object Parameter

image

    1. The Structure of a Simulation Object Parameter

      Many of the files in the object parameter database uses MAK Technologies LISP (MTL). (For details about MTL, please see “MÄK Technologies Lisp (MTL) Files,” on page A-3.) A parameter block has the form:

      (block_name

      ( parameter_name value)

      ...

      (parameter_name

      (sub-parameter value)

      )

      and so on

      )

      Entries have the following requirements:

      • The block_name can be anything that you like. It must not start with a number.

      • The parameter_name must be exactly as documented (except that in some cases, a parameter may contain an arbitrary length list of sub-parameters, for which the parameter names are not used – these will be noted). Parameter names must not contain spaces, and must not start with a digit (or a dash followed by a digit, for example, -1).

      • The first parameter in any parameter block must be parameter-type.

      • You can include comments in the file. A comment begins with a semicolon(;) and continues to the end of the line.

      • All numerical parameters use standard MKS values: meters, kilograms, seconds, radians, liters, and so on.

      • Real constants must begin with a digit and contain a decimal point. For example,

        0.5 and 0. are acceptable, but .5 and 0 are not.


        image

        i .entity files use XML format, not MTL.

        image


    2. The Parameter Type Hierarchy

Figure 69-4, in “Parameter Types,” on page 69-8, illustrates the hierarchy of parameter types. In this section, we describe the parameters associated with each parameter-type.


      1. Vrf Base Object Parameters

        All object parameters inherit from the parameter type vrf-base-object-param. The parame- ters associated with vrf-base-object-param are potentially applicable to any type of object (ground, rotary-wing, control object, and so on). Please see the General Parame- ters topic in the OPD Editor online help for parameter descriptions. In addition to parameters, each object has an object type and parameter type, as described in Table

        C-1.

        image

        Table C-1: Object and parameter type


        Parameter Description

        Parameter Description

        object-type (Required) 8-digit object type. Not actually a parameter. Specifies the key used to look up the entry. For more information, please see “Object Types,” on page 69-4.

        parameter-type (Required) One of the following (string):

        • "vrf-base-object-param"

        • "vrf-object-param"

        • "moving-object-param"

        • "fixed-wing-entity-param"

        • "ground-vehicle-param"

        • "rotary-wing-entity-param"

        • "missile-param"

        • "surface-entity-param"

        • "subsurface-entity-param"

        • “human-param”

        • “aggregate-object-param”

        • “cultural-feature-param”

        • “bomb-param”

        • “global-environment-param”

        • “circle-object-param”

        • “point-object-param”

        • “scripted-movement-object-param”

        • “tactical-smoke-param”.

          The value must be in quotation marks.

          image


          Local Objects Subcomponent Parameters

          The local-objects parameter specifies the types of subcomponents to create for locally simulated objects. You can omit optional items, or set them with an empty string “”. Table C-2 lists the subcomponent parameters and their possible values.

          image

          Table C-2: Local-objects subcomponent parameters (Sheet 1 of 2)


          Subcomponent Description parameter

          Subcomponent Description parameter

          state-repository (Required) Maintains the state information for the object. An object that has components (sensors, controllers, and actuators) for simulation sets and retrieves information in the repository.

          Some simulation components expect a specific kind of state repository. In general, you will want to specify the state reposi- tory type that most closely matches the kind of simulation object you expect to simulate. May be one of the following types:

          • "vrf-object-base-state-repository": Used for the base object in the object parameter database.

          • "vrf-object-state-repository": Derived from vrf-object-base- state-repository, it adds the concepts of resources, sector of responsibility, engagement rules, and targeting. Because there are more simulation object-specific state repository types that are derived from this type, this kind of repository is not typi- cally specified.

          • “vrf-overlay-object-state-repository”: For tactical graphics.

          • "vrf-moving-object-state-repository": For any object that you expect to simulate movement. Units in entity-level scenarios have this kind of state repository. The more simulation object- specific repository types that follow inherit this kind of state repository, so choose one of those when simulating a specific type of individual entity.

          • "ground-entity-state-repository": For ground vehicles, such as tanks, trucks, dismounted infantry.

          • "rotary-wing-entity-state-repository": For rotary-wing aircraft.

          • "fixed-wing-entity-state-repository": For fixed-wing aircraft.

          • "missile-entity-state-repository": For missile and rocket enti- ties.

          • "surface-entity-state-repository": For surface entities.

          • "subsurface-entity-state-repository": For subsurface entities.

          • “human-state-repository”: For lifeform entities.

          • “vrf-aggregate-state-repository”: For units.

          • “cultural-feature-state-repository”: For cultural features that are created as entities.

            image


            image

            Table C-2: Local-objects subcomponent parameters (Sheet 2 of 2)


            Subcomponent Description parameter

            Subcomponent Description parameter

            network-interface (Optional) The network interface handles the publication of the object over the network. It acts as an interface between a simula- tion object’s state repository and its network (VR-Link) represen- tation. Choose one that most closely matches the kind of simulation object you are simulating. May be one of the following types:

          • "vrf-object-state-repository": Derived from vrf-object-base- state-repository, it adds the concepts of resources, sector of responsibility, engagement rules, and targeting. Because there are more simulation object-specific state repository types that are derived from this type, this kind of repository is not typi- cally specified.

          • "vrf-overlay-object-state-repository": For tactical graphics.

          • "vrf-moving-object-state-repository": For any object that you expect to simulate movement, including individuals and units.

          • "ground-entity-state-repository": For ground vehicles, such as tanks, trucks, dismounted infantry.

          • "rotary-wing-entity-state-repository": For rotary-wing aircraft.

          • "fixed-wing-entity-state-repository": For fixed-wing aircraft.

          • "missile-entity-state-repository": For missile and rocket enti- ties.

          • “human-state-repository”: For lifeform entities.

          • “vrf-aggregate-state-repository”: For units.

          • “cultural-feature-state-repository”: For cultural features that are created as entities.

          • "surface-entity-state-repository": For surface entities.

          • "subsurface-entity-state-repository": For subsurface entities.

            image


            image

            Table C-3: Remote object subcomponent parameters (Sheet 2 of 2)


            Subcomponent

            parameter Description

            Subcomponent

            parameter Description

            network-interface (Optional) The network interface is the interface between the remote network (VR-Link) representation of the object and its state repository. It acts as an interface between a simulation object’s state repository and its network (VR-Link) representa- tion. Choose one that most closely matches the kind of simula- tion object you are simulating. May be one of the following types:

          net-interface-min-tick- period


          net-interface-min-tick- period-variance

          (Optional) Specifies the shortest period of time, in seconds, that can elapse between ticks of a simulation object’s network inter- face.

          (Optional) Specifies an amount within which the net-interface-min-tick- period can vary. Defined as:

          plus or minus rand(net-interface-min-tick-period/2)

          plan-manager Do not specify a plan manager for remote objects. (Give it the value "" (empty string). If you specify a plan manager, it is ignored.)

          component-manager Do not specify a component manager for remote objects. (Give it the value "" (empty string). If you specify a component manager, it is ignored.)

          task-manager (Optional) Do not specify a task manager for remote objects. (Give it the value "" (empty string). If you specify a task manager, it is ignored.)

          image


      2. Vrf Object Parameters

        The parameter type vrf-object-param inherits from vrf-base-object-param and is the parent of the moving object parameter type. Vrf object parameters include resources, engage- ment rules, and target acquisition time. The vrf-object-param parameter type represents an intermediate class in the parameter hierarchy. It is not usually used to represent objects in VR-Forces. You will probably want to instantiate a derived type, (for simula- tion objects) or you will want to specify vrf base object parameters (for case of control objects.)

        Control objects have the parameter type vrf-base-object-param.

        Object Parameters — Simulation Object Parameters

        image

      3. Moving Object Parameters

        Moving objects have the parameter type moving-object-param. Moving objects inherit parameters from vrf objects and vrf base objects. The moving-object-param parameter type is used for objects that are capable of movement, such as simulation objects. Parameters include support points, maximum speed, maximum reverse speed, turning radius, maximum slope, ordered speed, maximum acceleration, maximum deceleration, and fuel efficiency. Units are moving objects and have this parameter type. All of the plat- form-specific parameter types derive from this one.


      4. Parameter Types for Entity Platforms

Table C-4 lists the parameter types used by each entity type.

Table C-4: Parameter types for simulation objects


Platform

Parameter Type

Inherits from

Ground vehicle

ground-vehicle-param

moving-object-param

Fixed-wing

fixed-wing-entity-param

moving-object-param

Human

human-param

moving-object-param

Rotary-wing

rotary-wing-entity-param

moving-object-param

Surface

surface-entity-param

moving-object-param

Subsurface

subsurface-entity-param

moving-object-param

Cultural feature

cultural-feature-param

moving-object-param

Missile

missile-param

moving-object-param

Unit

aggregate-param

moving-object-param

Unit Container

moving-object-param

vrf-object-param


    1. Simulation Object Parameters

      For descriptions of simulation object parameters, please see the descriptions of indi- vidual components in the OPD Editor online help.


    2. Object Type Enumerations

      This section lists the object type enumerations as listed in the header file objType- Enums.h. It is presented here primarily for customers who have purchased VR-Forces, but not the toolkit. Therefore we have departed from the typical header file format for readability.


      1. Object Super-type

        The header file objTypeEnums.h contains the VR-Forces extensions to the DIS/RPR FOM enumerations. The enumerations specify individual, unit, and other object types. The sim object super-type is an enumeration used in the DtObjectType class (an exten- sion of the DtEntityType class). It extends the DIS/RPR FOM entity type enumeration by specifying the sort of object associated with the DtEntityType. Because object types are not guaranteed to be unique across all of the possible individual and unit types, the extra enumerated field provides a way to uniquely identify all objects in a VR-Forces simulation.

        VR-Forces uses the value 3 in the object super-type for all of the units that it simulates.

        Other 0 Individual 1

        Unit 2

        Disaggregated Unit 3

        Aggregated Unit 4

        Interaction 5

      2. AggregateKind

        The enumeration for DtAggregateKind should start with 0, but VR-Forces starts with 10, to ensure that simulation object types will be unique.

        Other 10

        MilitaryHierarchy 11

        CommonType 12

        CommonMission 13

        SimilarCapabilities 14

        CommonLocation 15

        DtSimArtPartKind 20

      3. ObjectKind

        Extension of entity kind to represent non-simulation object objects, such as control objects (control points, routes, phase lines, obstacles, and so on.)

        DtPointObjectKind 16

        DtLinearObjectKind 17

        DtArealObjectKind 18

        DtCircleObjectKind 19

        DtTextObjectKind 20


      4. Unit Category

        VR-Forces extends the enumeration to include DtAggregateCategoryForce, which represents the force level. All of the entries from Force through the end of the list, are extensions to the standard.

        Other 0

        IndividualVehicle 1

        Element 2

        Platoon 3

        Battery 4

        Company 5

        Battalion 6

        Regiment 7

        Brigade 8

        Division 9

        Corps 10

        Force 11

        Team 12

        Squad 13

        Section 14

        Unit Subcategory

        The Subcategory field enumerations for Kind field = Military Hierarchy specify the Echelon Type of the unit. Not all of the echelon types are applicable to each of the cate- gories.

        In the following list, ForceFriendly, ForceOpposing, ForceNeutral, and ForceOther are extensions to the DIS/RPR FOM enumerations.


        Other

        0

        ArmyAviationFixedWing

        13

        CavalryTroop

        1

        ArmyAviationRotaryWing

        14

        Armor

        2

        ArmyAttackHelicopter

        15

        Infantry

        3

        AirCavalry

        16

        MechanizedInfantry

        4

        ArmorHeavyTaskForce

        17

        Cavalry

        5

        MotorizedRifle

        18

        ArmoredCavalry

        6

        MechanizedHeavyTaskForce

        19

        Artillery

        7

        CommandPost

        20

        SelfPropelledArtillery

        8

        CEWI

        21

        CloseAirSupport

        9

        TankOnly

        22

        Engineer

        10

        ForceFriendly

        23

        AirDefenseArtillery

        11

        ForceOpposing

        24

        AntiTank

        12


      5. Unit Specific

        The Specific field enumerations for Kind field = Military Hierarchy specify whether the unit contains a headquarters, and is enumerated as follows.

        Noheadquarters 0

        ContainsHeadquarters 1


      6. Point Object Category

        Subcategories for use with the Kind field = DtPointObjectKind.

        Other 0 ControlPoint 1

        TargetPoint 2

        Marker 3


      7. Linear Object Category

        Subcategories for use with the Kind field = DtLinearObjectKind.

        Other 0 PhaseLine 1

        Route 2


      8. Areal Object Category

        Subcategories for use with the Kind field = DtArealObjectKind.

        Other 0 ControlArea 1

        Obstacle 2


      9. Interaction

Kinds for Supertype interaction.

Other 0 Fire 1

Detonate 2


image D. Systems and System Usage


The tables in this appendix provide information about the systems provided with VR- Forces and list the simulation objects that use them.

VR-Forces Systems....................................................................................... D-2


    1. VR-Forces Systems

      The following tables list systems used for entity-level scenarios and aggregate-level scenarios:

      • Table D-1 lists all of the systems provided with the EntityLevel.sms and provides information about them.

      • Table D-2 lists each system and the entity types that use it.

      • Table D-3 lists systems and the scripted tasks configured in them for Enti- tyLevel.sms.

      • Table D-4 lists the systems for AggregateLevel.sms.

      • Table D-5 lists the system and entity types for AggregateLevel.sms.

      • Table D-6 lists systems and the scripted tasks configured in them for Aggre- gateLevel.sms.


image

Table D-1: System descriptions, EntityLevel.sms


System Category Entity Types Description

System Category Entity Types Description

120mm Gun weapon ground Turreted 120mm gun, typical of

tanks such as the M1A2. Fires M829A1-AP and M830-HEAT

rounds. Targets ground vehicles.

125mm Gun weapon ground Turreted 125mm gun, typical of

tanks such as the T-80. Fires both BM-9-AP and BM-14m- HEAT rounds. Targets ground vehicles.

14.5mm Quad Gun

weapon ground ADA Quad Machine Gun , multi-

barreled machine gun used for ADA. Found on ZPU-4. 14.5mm rounds. Targets Air entities.

25mm Gun weapon ground Turreted 25mm gun. Fires

M791-AP 25mm rounds. Targets ground vehicles.

30mm Gun weapon ground Turreted 30mm gun. Fires AT-

30mm rounds. Targets ground vehicles.

OTO Melara 76mm Naval Gun


Active RADAR Sensor

weapon surface Turreted indirect fire weapon.

Fires 76mm rounds on command.

sensor all Allows an entity to detect other objects through RADAR. Also publishes emitter beams that represent the emissions from the sensor.


image


Section XIV - Appendixes

D-2 VT MAK


Active SONAR Sensor

sensor all Allows an entity to detect other objects through SONAR.

Air Aggregate movement aggregate Basic movement capabilities for

any air-based aggregate, fixed wing or rotary wing.

Air Cushion movement ground Air cushion movement; allows

entity to cross both land and water.

Airborne Targeting RADAR

sensor fixed-wing, rotary-wing

RADAR used by aircraft to detect targets. Publishes an emitter beam.

Cargo Door other rotary-wing, fixed-wing, ground, surface

Sliding Door other rotary-wing, fixed-wing, ground, surface

Articulates the opening and closing of a cargo door.


Articulates the opening and closing of a sliding door.

Anti-Submarine Missile (Vertically Launched)

weapon surface Missile launched from deck of

ship, flies out to submarine target and drops a homing torpedo.

Building Default Damage

damage cultural- feature

Default damage system for a building.

CIS Air Defense Missile Package


CIS Attack Heli- copter Missile Package


CIS Attack/Strike Missile Package


CIS Counter Measures Launcher

weapon fixed-wing Missile launcher with loadout for

CIS air defense entity. Fires Aphid AA-8 missiles against air targets and Kedge AS-14 missiles against ground targets.

weapon rotary-wing Missile launcher with loadout for

CIS attack helicopter. Fires Archer AA-11 missiles against air targets and Spiral AT-6 missiles against ground targets.

weapon fixed-wing Missile launcher with loadout for

CIS attack/strike entity. Fires Aphid AA-8 missiles against air targets and Kerry AS-7 missiles against ground targets.

other all Allows an entity to launch counter measures for self defense. Configured with CIS flares and chaff.


image


CIS Fighter Bomber Bomb Bay


CIS Heavy Bomber Bomb Bay

weapon fixed-wing, rotary-wing


weapon fixed-wing, rotary-wing

Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.

Configured to launch bombs manufactured in the Common- wealth of Independent States.

Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.

Configured to launch bombs manufactured in the Common- wealth of Independent States.

Counter Measures Launcher


Vehicle Exposed Crew Suppression

other all Allows an entity to launch counter measures for self defense.

other ground Suppression model for vehicles

with exposed crew members.

Cruise Missile movement fixed-wing Cruise missile flight dynamics.

Fast and maneuverable, but with limited tasking capabilities.

DDG Embedded Support Craft (LAMPS/RHIB)


DI Laser Desig- nator


Exocet Cruise Missile Launcher (Forward Launched)

other all System that allows an entity to deploy and recover Embedded Entities appropriate to a ship with supporting LAMPS units.

other all A laser designator, which can aim a laser at targets. For use with a laser guided missile delivery system. This laser designator can be explicitly tasked to designate particular targets, or set to autonomous lasing mode. In autonomous lasing mode, the laser will auto- matically designate hostile ground vehicles.

weapon fixed-wing Launcher for Exocet anti-ship

cruise missiles. Launches missiles forward of the entity, appropriate for aircraft.

Exocet Cruise Missile Launcher (Vertically Launched)

weapon surface, ground

Launcher for Exocet anti-ship cruise missiles. Launches missiles at an upward angle, appropriate for ships.

Explosive Device weapon all Explosive device system. Allows

3 types of detonations -- instant, time-delayed, and proximity.

image


Section XIV - Appendixes

D-4 VT MAK


Fall From Sky Dynamics

movement all Movement dynamics for based on gravity and drag of object.

Fast Roping other all Allows troops to fast rope from

this vehicle.

Maverick Missile Launcher

weapon fixed-wing Fixed Maverick Missile Launcher.

Fires Air-To-Ground missiles at ground targets. Fixed to the entity (no turret) and always fires forward.

Sidewinder Missile Launcher

weapon fixed-wing, rotary-wing

Fixed Sidewinder Missile Launcher. Fires Air-To-Air missiles at air targets. Fixed to the entity (no turret) and always fires forward.

Fixed Wing Default Armor

damage fixed-wing Basic armor for a fixed-wing

aircraft.

Fighter Jet movement fixed-wing Fighter jet, such as the A-10. Heavy Plane movement fixed-wing Heavy plane flight dynamics,

such as a cargo plane.

High Maneuver- ability Fighter

Frictionless Gravity Dynamics

Frictionless Gravity Dynamics With Collisions

movement fixed-wing Highly maneuverable fighter jet,

such as the F-16.

movement all Movement dynamics solely based on gravity.

movement all Movement dynamics solely based on gravity.

GAU-8 Avenger weapon fixed-wing GAU-8 30mm gatling gun, found

on the U.S. A-10 ground attack aircraft. Used for attacking armor and other vehicles.

Gimbaled Visual Sensor

sensor all Allows an entity to detect other objects through visible light.

Grenade Warhead weapon all Grenade warhead. Will explode

based on the fuse of the muni- tion resource used to launch it.

Ground Aggre- gated Movement

aggregated aggregate Basic movement capabilities for

any ground-based aggregated unit, both vehicle and DI.

Ground Convoy Movement

disaggre- gated

aggregate Basic movement capabilities for

any ground-based convoy unit.


image


Ground Disaggre- gated Movement

disaggre- gated

aggregate Basic movement capabilities for

any ground-based disaggregated unit, both vehicle and DI.

Heavy Armor damage ground Heavy armored ground vehicle,

such as a tank.

Light Armor damage model

damage ground Component that computes

damage for lightly armored ground vehicles. Maps munition types to damage tables.

Tracks movement ground Movement model for ground

entities with tracks.

Tracks/Amphib- ious

movement ground Amphibious tracked vehicles that

can move over land and water.

No Armor damage ground, vrf object

Unarmored ground vehicle, such as a civilian vehicle.

Wheels (off road) movement ground Wheeled vehicle designed for off

road use, such as a HMMWV. Can switch into road following mode.

Wheels (road) movement ground Wheeled vehicle designed for on-

road use, such as a civilian car. Limited mobility off roads.

GSh-301 Cannon weapon fixed-wing GSh-301 30mm cannon used on

Russian attack aircraft. Used for attacking ground and air targets.

AK-47 weapon human Handheld AK-47 rifle. Targets

human entities.

AT4 weapon human Handheld AT4 Anti-Tank weapon. Targets ground vehicles and helicopters.

Throw Grenades other human Person throws a grenade M16 rifle weapon human Handheld M16 rifle. Targets

human entities.

Handheld M240B Machine Gun

weapon human Hand carried M240B 7.62mm

Machine Gun. Targets lifeforms.

M249 SAW weapon human M249 Squad Automatic

Weapon, 5.56mm fully auto- matic rifle. Targets lifeforms.

Handheld M60 Machine Gun

weapon human Hand carried M60 7.62mm

Machine Gun. Targets lifeforms.


image


Section XIV - Appendixes

D-6 VT MAK


RPG Launcher weapon human Handheld RPG Launcher.

Targets ground vehicles and heli- copters.

Handheld UAV movement fixed-wing Handheld / hand-launched UAV

such as the RQ-11 Raven.

Homing Torpedo Capability (Forward Launched)

weapon subsurface, surface, rotary-wing, fixed-wing

Homing torpedo capability. Launched from forward tubes.

Human Disaggre- gated Movement

disaggre- gated

aggregate Basic movement capabilities for

any human disaggregated unit, both vehicle and DI.

Suicide Vest weapon human Explosive device system that is

worn by a lifeform.

Flee From Explo- sions

other human Enables a behavior of automati-

cally fleeing from nearby explo- sions.

Human Default movement human Default movement dynamics for

human entities. Manages move- ment and posture.

IFF Transponder other all Sends IFF data, when turned on.

IFF is off by default.

IR Sensor sensor all Allows an entity to detect other

objects through Infrared.

Laser Designator other all A laser designator, which can

aim a laser at targets. For use with a laser guided missile delivery system. This laser designator can be explicity tasked to designate particular targets, or set to autonomous lasing mode. In autonomous lasing mode, the laser will auto- matically designate hostile ground vehicles.

Hydra 70 APKWS Launcher

weapon fixed-wing, rotary-wing

Launches APKWS rockets at targets that are lased with the laser code matching the one set in the launcher. Can only fire on targets designated with a laser.


image


Laser Guided Hell- fire Missile Launcher

weapon fixed-wing, rotary-wing

Launches Hellfire missiles at targets that are lased with the laser code matching the one set in the launcher. Can only fire on targets designated with a laser.

Laser Guided Missile Dynamics

movement missile Movement dynamics for a laser

guided missile. A missile using this type will require a laser on its target.

Default Armor damage human Basic damage model for lifeform

entities.

Lifeform Suppres- sion

Limit Entity Exis- tence


M1A2 Main Gun and MGs

other human Suppression model for lifeform

entities.

other all Used to control the life span of the object this system is attached to. Once it's life span is up the object is removed from the simulation.

weapon ground The turret for an M1A2 tank,

including the 120mm main gun, the coax MG, the commander's MG, and the loader's MG.

M2HB Machine Gun

weapon ground, surface

Turreted M2 .50 Caliber Machine Gun, typical of the secondary gun on tanks such as the M1A2. M2 12.7mm rounds. Targets life- forms. Also used on small boats and can target boats.

M203 Grenade Launcher

other human Launch grenade with attached

M203

M230 Chain Gun weapon ground,

rotary-wing

M230 chain gun, mounted on the AH-64 Apache. Fires High Explosive Dual Purpose rounds that can penetrate 2 inches of armor, and that fragment to kill soft targets.

M240 Machine Gun

weapon ground, rotary-wing

Vehicle mounted M240 7.62mm Machine Gun. Typical secondary gun on tanks such as the M1A2. Targets lifeforms and unarmored vehicles.

M250 smoke grenade launcher

other all Allows an entity to launch thermal obscuring white phos- phorous (WP) smoke.


image


Section XIV - Appendixes

D-8 VT MAK


M252 81mm

mortar

M270 MLRS

Launcher


M284 155mm

Cannon

weapon human, ground

weapon ground Turreted indirect fire weapon.

Fires M26 rockets on command. Targets must be at least 2km away.

weapon ground Turreted indirect fire weapon.

Fires 155mm M107 rounds on command. Targets must be at least 2km away.

M60 Machine Gun

weapon ground, rotary-wing

M60 7.62mm Machine Gun, typical vehicle machine gun. Replaced by M240. Targets life- forms and unarmored vehicles.

M61 Vulcan weapon fixed-wing M61 20mm gatling gun, found

on the U.S. attack aircraft. Used for attacking ground and air targets.

MAD Sensor sensor all Allows an entity to detect

Subsurface entities using Magnetic Anomaly Detection.

Missile Default Armor

damage missile, fixed- wing, scripted- movement

Basic armor for a missile.

Guided Missile Dynamics

movement missile Movement dynamics for a basic

guided missile.

Missile Warhead weapon fixed-wing,

subsurface, surface

Missile warhead. It explodes as soon as it hits another entity, the ground, or the surface of the water.

MK 45 Naval Gun weapon surface Turreted indirect fire weapon.

Fires 127mm rounds on command.

Naval Depth Charge Deploy- ment

weapon fixed-wing Depth charge release system for

naval depth charges.

Naval Mine Deployment

weapon fixed-wing, subsurface, surface

Mine release system for naval (underwater) mines.

Naval Mine Dynamics

movement all Movement dynamics based on gravity and drag of object. Will also allow the object to stop at a certain altitude.


image


Naval Mine Explo- sive Device


Naval Mine Sweep

Other Explosive Device


Passive RADAR Sensor


Passive SONAR Sensor

Patriot Missile Launcher

weapon bomb Naval Mine device system.

Allows 3 types of detonations -- instant, time-delayed, and prox- imity.

other surface Execute task to sweep and

disable naval mines.

other all Explosive device system for objects which do not normally have weapon systems. Allows 3 types of detonations -- instant, time-delayed, and proximity.

sensor all Allows an entity to detect other objects through RADAR. No emitters are published for this sensor.

sensor all Allows an entity to detect other objects through SONAR.

weapon ground Turreted Patriot Missile

Launcher. Targets air vehicles.

Pedestrian Crowd Movement

disaggre- gated- movement

all Movement capabilities for pedes- trian crowds.

Pedestrian Traffic Generator

other all Makes tasks available for pedes- trian traffic generation within the area defined by the object or the radius defined below.

Periscope other subsurface System that will allow modeling

of a periscope.

Rotary Wing Attack

Rotary Wing Default Armor

movement rotary-wing Attack Helicopter, such as the A- 64.

damage rotary-wing Basic armor for a rotary wing

aircraft.

Cargo movement rotary-wing General Cargo helicopter, such

as the CH-53 Super Stallion.

Quadcopter Heavy Lift

movement rotary-wing Movement dynamics for very

small, low altitude UAV and Quadcopter type vehicles

Quadcopter movement rotary-wing Movement dynamics for very

small, low altitude UAV and Quadcopter type vehicles

Dipping SONAR Sensor

sensor rotary-wing Allows an entity to detect other

objects through SONAR.


image


Section XIV - Appendixes

D-10 VT MAK


Utility movement rotary-wing General utility helicopter, such as

the UH-60 Blackhawk.

VTUAV movement rotary-wing General Vertical Takeoff

Unmanned Aerial Vehicle such as the Dragon Warrior.

SA-9 SAM Missile Launcher

weapon ground Turreted surface-to-air missile

launcher which fires SA-9 missiles. Targets air vehicles.

Scripted Move- ment

scripted- movement

scripted- movement

System that will allow for scripted movements.

Small boat movement surface Movement dynamics for small

boats.

Bomb Dynamics movement bomb Movement dynamics for a guided

smart bomb.

SONAR Sensor sensor all Allows an entity to detect other

objects through SONAR.

Sonobuoy Deployer

other all System that allows an entity to deploy sonobuoys.

Space Shuttle movement fixed-wing Based on the heavy plane flight

dynamics.

Spot Report Generator


Spot Report Receiver


Stinger Missile Launcher


Subsurface Entity Default

other all Allows the entity to send spot reports through its radio when its sensors detect other entities in the scenario.

other all Allows an entity to receive spot reports from other entities over the radio, and add these contacts to its list of known enti- ties. By default, spot reports expire after 5 minutes.

weapon ground Turreted Stinger Missile

Launcher. Targets air vehicles between 1km and 8km away, and fires guided stinger missiles at them.

damage subsurface Basic damage model for subsur-

face entities.

Subsurface movement subsurface Movement dynamics for a

subsurface vessel.

Surface Entity Default

damage surface Basic damage model for a

surface vessel.


image


Surface Disaggre- gated Movement

disaggre- gated

aggregate Basic movement capabilities for

any surface-entity-based disag- gregated unit.

Large Ship movement surface Movement dynamics for a large

ship.

Surface Multiple Hit Damage

Small Surface Ships


Tactical Radar Jammer

Tanker Refueling Boom

damage surface Hit point based surface damage

model.

damage surface Damage model for small boats

such as inflatables, sailboats, or small patrol boats.

other all Multi-mode ECM tactical jamming system.

other fixed-wing Articulates the deploying and

stowing of a refueling boom on a tanker aircraft.

Torpedo Warhead weapon subsurface,

surface

Torpedo warhead. It explodes as soon as it hits another entity, the ground, but not the surface of the water. Can also explode proximal to entity.

TOW Missile Launcher

weapon ground Turreted TOW Missile Launcher.

Targets ground vehicles.

US Fighter Bomber Bomb Bay


US Heavy Bomber Bomb Bay


Vertical SAM Missile Launcher

weapon fixed-wing, rotary-wing


weapon fixed-wing, rotary-wing


weapon ground, surface

Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.

Configured to launch bombs manufactured in the United States of America.

Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.

Configured to launch bombs manufactured in the United States of America.

Surface-to-air missile launcher which fires SM-2 missiles.

Targets cruise missiles.

Visual Sensor sensor all Allows an entity to detect other

objects through visible light.

image


Section XIV - Appendixes

D-12 VT MAK


120mm Gun AMX-10RC (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT,

Arjun MBT (No 3D), C1 Ariete MBT (No 3D), Centauro B1 (No 3D), EE-9 Cascavel (No 3D), ERC 90 Sagaie (No 3D), FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), K1A1 MBT (No 3D), Leopard 2 Tank, Merkava III MBT (No 3D), Merkava IV MBT (No 3D), MO-120RT-61 Mortar, Panhard AML- 245 (No 3D), PT-91 Twardy MBT (No 3D), Type 10 MBT (No

3D), Type 90 Kyu-maru MBT (No 3D)

125mm Gun MBT 2000 (No 3D), T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Type 99 MBT (No 3D)

14.5mm Quad Gun

ZPU-4 AA Gun, ZSU-23-4 Shilka

25mm Gun Coyote APC (No 3D), Dardo IFV (No 3D), Freccia IFV (No 3D), FV101 Scorpion CVR, LAV III APC, M2A2 Bradley IFV, M3A2 Bradley CFV, MBT 2000 (No 3D), T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Type 99 MBT (No 3D), VBCI APC (No 3D), Wiesel AWC (No 3D), XM7 FIST-

Bradley

30mm Gun ASCOD Ulan AIFV (No 3D), BMP-1 AFV, BMP-2 AFV, BTR-80

APC, BTR-90, Cadillac Gage Commando V-150 (No 3D), CV9035 AFV, FV 510 Warrior (No 3D), FV107 Scimitar, Pomornik (Zubr)-class LCAC (No 3D), Type 85 (YW 531H) APC (No 3D)

OTO Melara 76mm Naval Gun

Brandenburg-class Frigate (No 3D)


image


Active RADAR Sensor

Admiral Grigorovich-class Frigate (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Albatros-class Fast Attack (No 3D), Patriot Radar AN/MPQ-65, Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Sentinel R1 (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig- class Corvette (No 3D), Bremen-class Frigate (No 3D), Cape- class Patrol Boat (No 3D), Charles De Gaulle R91 (No 3D), Dabur-class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), Echo-class Survey Ship (No 3D), Eridan-class Minehunter (No 3D), F-22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal- class Minehunter (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Gaeta-class Minehunter, Gepard-class Frigate (No 3D), Grisha-class Corvette (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Hauk-class Fast Attack (No 3D), Henry J Kaiser-class Oiler (No 3D), Holland Class OPV (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), LCS Independence Class (No 3D), Invin- cible-class Carrier (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), Jacinto-class Corvette (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR-40 Clurit-class Fast Attack (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov- class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Patriot Air Defense System (PAC-3), Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Nanuchka III-class (No 3D), Neustrashimyy- class Frigate (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Pauk-class Corvette (No 3D), Pomornik (Zubr)-class LCAC (No 3D), Queen Elizabeth- class Carrier (No 3D), River-class Patrol Vessel (No 3D), Saar 4- class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sandown-class Minehunter (No 3D), Sentinel-class (WPC) (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Super Dvora Mark II (No 3D), Tarantul-class Corvette (No 3D), Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, National Security Cutter, Hamilton Class Cutter WHEC, Victor II- class Submarine (No 3D), Victory-class Corvette (No 3D), Marine Protector Class Patrol Boat

Section XIV - Appendixes

D-14 VT MAK


Active SONAR Sensor


Air Aggregate

Ahmad Yani-class Frigate, Alta-class Minehunter (No 3D), Aquit- aine-class Frigate (No 3D), Brandenburg-class Frigate (No 3D), Bremen-class Frigate (No 3D), De Zeven Provincien Class Frigate (No 3D), Eridan-class Minehunter (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), Fridtjof Nansen-class (No 3D), Grisha-class Corvette (No 3D), Hamina-class Fast Attack (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Niteroi- class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Pauk- class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sigma 9113-class Frigate, Sonobuoy (Passive), Steregushchiy-class Frigate (No 3D), National Security Cutter, Hamilton Class Cutter WHEC

Air Cushion Centauro B1 (No 3D), , LCAC, Pomornik (Zubr)-class LCAC (No 3D)

Airborne Targeting RADAR

A-10 Thunderbolt, A-4 Skyhawk (No 3D), AMX (No 3D), AV-8B Harrier II, B-2 Spirit, BAE CT-155 Hawk (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), Chengdu J-7 (No 3D), Cypher VTUAV, Dassault Atlantic (No 3D), Dragon Warrior VTUAV, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Harbin SH-5 ASW (No 3D), Hermes 450 (No 3D), Maveric UAS (No 3D), MiG-27 Flogger, MiG-29 Fulcrum, Mirage 2000, Mirage F1, MQ-4C Triton, MQ-8B Fire Scout, MQ- 9 Reaper UAV, Nanchang Q-5 (No 3D), P-3 Orion, MQ-1 Pred- ator, RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)

Cargo Door CH-149 Cormorant, CH-53E Super Stallion Sliding Door CH-149 Cormorant

Anti-Submarine Missile (Vertically Launched)

Building Default Damage

CIS Air Defense Missile Package

CIS Attack Heli- copter Missile Package

Arleigh Burke-class Destroyer, Kirov-class Guided Missile Cruiser (No 3D), Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Pauk-class Corvette (No 3D), Type 23 Frigate

Bottle, Building Warehouse Steel, POL Storage Tank, Shooting Target, Tower Radio

MiG-29 Fulcrum, SU-27 Flanker


KA-50 Hokum, Mi-24 Hind, Mi-28 Havoc


image


CIS Attack/Strike Missile Package


CIS Counter Measures Launcher


CIS Fighter Bomber Bomb Bay


CIS Heavy Bomber Bomb Bay

Counter Measures Launcher

Chengdu J-7 (No 3D), , MiG-27 Flogger, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, Su-37 Flanker

Chengdu J-7 (No 3D), , KA-50 Hokum, Mi-17 Hip (No 3D), Mi- 24 Hind, Mi-28 Havoc, MiG-27 Flogger, MiG-29 Fulcrum, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shen- yang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su- 37 Flanker, Tu-160 Blackjack (No 3D)

Chengdu J-7 (No 3D), , MiG-27 Flogger, MiG-29 Fulcrum, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shen- yang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su- 37 Flanker, Tu-160 Blackjack (No 3D)


A-10 Thunderbolt, A-4 Skyhawk (No 3D), AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), AMX (No 3D), Antonov-class (No 3D), AS 550 Fennec (No 3D), AS- 365 Dauphin (No 3D), AS-565 Panther (No 3D), AV-8B Harrier II, BAE CT-155 Hawk (No 3D), Bell 412 (No 3D), Bell 206

JetRanger (No 3D), Bell 406 (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), CH-148 Cyclone (No 3D), CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chengdu J-7 (No 3D), Dassault Atlantic (No 3D), E-2 Hawkeye, EA-6B Prowler, EC 135 (No 3D), EC 635 (No 3D),

EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EH101 Merlin (No 3D), Eurofighter Typhoon, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Harbin SH-5 ASW (No 3D), HH-65 Dolphin (No 3D), Il-76 Candid (No 3D), KA-50 Hokum, MD 500 (No 3D), MH-47 Chinook (No

3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi-2 Hoplite, MiG-27 Flogger, MiG-29 Fulcrum, Mirage 2000, Mirage F1, Nanchang Q-5 (No 3D), OH-58 Kiowa, P-3 Orion, RAH-66 Comanche, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Shen- yang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU- 25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), UH-1N Twin Huey (No 3D), UH- 60 Blackhawk, UH-72 Lakota (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D), Xian JH-7 (No 3D)


image


Section XIV - Appendixes

D-16 VT MAK


Vehicle Exposed Crew Suppression

AAVC7A1 Landing Vehicle, Dardo IFV (No 3D), Freccia IFV (No 3D), HMMWV with Avenger, HMMWV with M2, HMMWV with TOW launcher, L-118 Howitzer (No 3D), LAV III APC, Leopard 2 Tank, LG1 Howitzer (No 3D), M-71 Howitzer (No 3D), M113 APC, M1A2 Abrams MBT, M252 Mortar, M577A2 Command Post, Technical Truck, VAB APC, ZPU-4 AA Gun

Cruise Missile Exocet Cruise Missile, RUR-5 ASROC

DDG Embedded Support Craft (LAMPS/RHIB)

DI Laser Desig- nator

Exocet Cruise Missile Launcher (Forward Launched)

Exocet Cruise Missile Launcher (Vertically Launched)

Arleigh Burke-class Destroyer, Kirov-class Guided Missile Cruiser (No 3D), Slava-class Guided Missile Cruiser (No 3D)


DI Lasing (CIS), DI Lasing (US)


Dassault Atlantic (No 3D), MiG-27 Flogger, Mirage 2000, SU-25 Frogfoot, Su-37 Flanker, Tu-160 Blackjack (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)


Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Durand de la Penne-class Destroyer (No 3D), Fatahillah- class Frigate (No 3D), Floreal-class Frigate (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax- class Frigate (No 3D), Hauk-class Fast Attack (No 3D), Horizon- class Destroyer (No 3D), Iroquois-class Destroyer (No 3D), KD- III-class Destroyer (No 3D), Khareff-class Corvette (No 3D), Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), La Fayette-class Frigate (No 3D), Moudge- class Frigate (No 3D), Niteroi-class Frigate (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sigma 9113-class Frigate, Skjold- class Patrol (No 3D), Sovremennyy-class Destroyer, Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 22 Frigate (No 3D), Udaloy-class Destroyer, Victory-class Corvette (No 3D)

Explosive Device Car Bomb, Duffle Bag, Naval Mine, Quickstrike Mk 65, Roadside IED, Sea Lance ASW, Suicide Bomber

Fall From Sky Dynamics

CIS Chaff, CIS Flare, US Chaff, US Flare

Fast Roping CH-149 Cormorant, MH-60 Black Hawk, SH-60 Seahawk, UH- 60 Blackhawk

Maverick Missile Launcher

A-10 Thunderbolt, A-4 Skyhawk (No 3D), AV-8B Harrier II, EA- 6B Prowler, Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Light- ning II, F/A-18 Hornet, Mirage F1, P-3 Orion, MQ-1 Predator, Tornado ADV (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)


Sidewinder Missile Launcher


Fixed Wing Default Armor

A-10 Thunderbolt, A-4 Skyhawk (No 3D), AMX (No 3D), AV-8B Harrier II, BAE CT-155 Hawk (No 3D), Eurofighter Typhoon, F- 117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Mirage F1, Tornado ADV (No 3D), Xian JH-7 (No 3D)

A-10 Thunderbolt, A-4 Skyhawk (No 3D), Ababil UAV (No 3D), Airbus 310, Airbus 320 - American Airlines, Airbus 320 - British Airways, Airbus 320 - Lufthansa, Airbus 320 - Singapore Airlines, Airbus 380 (No 3D), AMX (No 3D), AT-802 (No 3D), AV-8B Harrier II, B-2 Spirit, Beechcraft 36 Bonanza (No 3D), Beechcraft C-12 Super King (No 3D), Beechcraft T-6 (No 3D), BN-2 Islander (No 3D), Boeing 707, Boeing 737 British Midland, Boeing 747-400, Boeing 757 (No 3D), Boeing 767 (No 3D), Boeing 777 (No 3D), Boeing 787 (No 3D), Bombardier CL-600 (No 3D), Bombardier DHC-8 (No 3D), Sentinel R1 (No 3D), Bombardier CRJ100 Conrad Air, Bombardier CRJ200 Air France, C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), CASA C-212 Aviocar (No 3D), Cessna 172 Skyhawk, Cessna Citation (No 3D), Chengdu J-7 (No 3D), Dassault Atlantic (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), Dornier DO 228-200 LGW, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EADS CASA C-295 (No 3D), EMT Aladin (No 3D), EMT Luna (No 3D), Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Gulfstream G550 (No 3D), Harbin SH-5 ASW (No 3D), Hermes 450 (No 3D), IAI 1124 Sea Scan (No 3D), KC-135 Stratotanker, Lockheed L-1011 (No 3D), Maveric UAS (No 3D), MiG-27 Flogger, MiG-29 Fulcrum, Mirage 2000, Mirage F1, Mohajer UAV (No 3D), MQ-4C Triton, MQ-9 Reaper UAV, Nanchang Q-5 (No 3D), P-3 Orion, MQ-1 Predator, RDE KZO (No 3D), RQ-11

Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Shen- yang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Space Shuttle, SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), Ultralight Trike, Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)

Fighter Jet A-10 Thunderbolt, AV-8B Harrier II, B-2 Spirit, Chengdu J-7 (No 3D), F-117A Nighthawk, MiG-27 Flogger, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, Su-37 Flanker, Tu-160 Blackjack (No 3D), Xian H-6 Badger (No 3D)

image


Section XIV - Appendixes

D-18 VT MAK


Heavy Plane Airbus 310, Airbus 320 - American Airlines, Airbus 320 - British Airways, Airbus 320 - Lufthansa, Airbus 320 - Singapore Airlines, Airbus 380 (No 3D), AT-802 (No 3D), Beechcraft 36 Bonanza (No 3D), Beechcraft C-12 Super King (No 3D), Beech- craft T-6 (No 3D), BN-2 Islander (No 3D), Boeing 707, Boeing 737 British Midland, Boeing 747-400, Boeing 757 (No 3D), Boeing 767 (No 3D), Boeing 777 (No 3D), Boeing 787 (No 3D), Bombardier CL-600 (No 3D), Bombardier DHC-8 (No 3D), Sentinel R1 (No 3D), Bombardier CRJ100 Conrad Air, Bombar- dier CRJ200 Air France, C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), CASA C-212 Aviocar (No 3D), Cessna 172 Skyhawk, Dassault Atlantic (No 3D), Dornier DO 228-200 LGW, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EADS CASA C-295 (No 3D), Gulfstream G550 (No 3D), Harbin SH-5 ASW (No 3D), IAI 1124 Sea Scan (No 3D), KC-135 Strato-

tanker, Lockheed L-1011 (No 3D), P-3 Orion, Ultralight Trike

High Maneuver- ability Fighter


Frictionless Gravity Dynamics

Frictionless Gravity Dynamics With Collisions

A-4 Skyhawk (No 3D), AMX (No 3D), BAE CT-155 Hawk (No

3D), Canadair CT-114 (No 3D), Cessna Citation (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), Eurofighter Typhoon, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Hermes 450 (No 3D), MiG-29 Fulcrum, Mirage 2000, Mirage F1, MQ-4C Triton, MQ-9 Reaper UAV, MQ-1 Predator, RQ-4 Global Hawk UAV, SAGEM Sperwer (No 3D), SU-27 Flanker, Tornado ADV (No 3D), Xian JH-7 (No 3D)

76mm Shell, M107 155mm, M26 Rocket, M374A2 81mm, M433, M583A1, M651, M713, M715, M716

M18_Green Smoke Grenade, M18_Red Smoke Grenade, M18_Violet Smoke Grenade, M18_Yellow Smoke Grenade, M67 hand grenade, M83 White Smoke, M84 Flash Bang

GAU-8 Avenger A-10 Thunderbolt

Gimbaled Visual Sensor

MQ-8B Fire Scout, MQ-9 Reaper UAV, MQ-1 Predator, SAGEM Sperwer (No 3D)

Grenade Warhead M18_Green Smoke Grenade, M18_Red Smoke Grenade, M18_Violet Smoke Grenade, M18_Yellow Smoke Grenade, M67 hand grenade, M83 White Smoke, M84 Flash Bang

Ground Aggre- gated Movement


Ground Convoy Movement

ADA Plt (CIS), ADA Plt (US), Armor Co (CIS), Armor Co (US),

Armor Co HQ (CIS), Armor Co HQ (US), Armor Plt (CIS), Armor Plt (US), COLT Team (CIS), COLT Team (US), CSS Plt (CIS), CSS Plt (US), DI Plt (CIS), DI Squad (CIS), DI Squad (US), FA

Battery (US), Ground Unit, MI Plt (CIS), MI Plt with IFV (US), USMC FT, USMC SQD, US Army LtInf FT, US Army LtInf SQD,

US Army Mech FT A (Javelin), US Army Mech FT B, US Army Mech SQD

Convoy


Ground Disaggre- gated Movement

ADA Plt (CIS), ADA Plt (US), Armor Co (CIS), Armor Co (US),

Armor Co HQ (CIS), Armor Co HQ (US), Armor Plt (CIS), Armor Plt (US), CSS Plt (CIS), CSS Plt (US), DI Squad (US), FA Battery (US), Ground Unit, MI Plt (CIS), MI Plt with IFV (US)

Heavy Armor AMX-30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT, Aravis MRAP (No 3D), Arjun MBT (No 3D), ASCOD Ulan AIFV (No 3D),

ATF Dingo (No 3D), Badger AEV (No 3D), Beaver AVLB (No 3D), Bergepanzer 2 ARV (No 3D), Buffalo MRAP III, Buffel ARV (No 3D), Bushmaster PMV (No 3D), C1 Ariete MBT (No 3D), CV9035 AFV, DNG/DCL (No 3D), EE-9 Cascavel (No 3D),

Freccia IFV (No 3D), Fuchs APC (No 3D), FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), GTK Boxer APC (No 3D), K1A1 MBT (No 3D), Leopard 2 Tank, M1A2 Abrams MBT, MBT 2000 (No 3D), Merkava III MBT (No 3D), Merkava IV MBT (No 3D), MOWAG Eagle (No 3D), MRAP-ATV, MRAP-CAT II

Cougar, MRAP-CAT I MaxxPro, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), RG-31 Nyala (No 3D), T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D),

Taurus ARV (No 3D), Type 10 MBT (No 3D), Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), VM 90 LSVW (No 3D)

Light Armor damage model

2S19 Msta-S (No 3D), Aardvark JSFU (No 3D), AAVC7A1

Landing Vehicle, Achzarit APC (No 3D), AMX-10RC (No 3D), AS-90 Artillery, ASTROS II MLRS (No 3D), AUF1 155mm

Howitzer (No 3D), Auverland A4 AVL (No 3D), Bandvagn 206 (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, BTR-60

APC, BTR-80 APC, BTR-90, Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Centauro B1 (No 3D), Cougar FSV, Coyote APC (No 3D), Dardo IFV (No 3D), ERC 90 Sagaie (No 3D), ESK Mungo (No 3D), FV 510 Warrior (No 3D), FV101

Scorpion CVR, FV107 Scimitar, FV432 APC (No 3D), Grizzly APC (No 3D), Husky ARV (No 3D), L-118 Howitzer (No 3D), LAPV Enok (No 3D), LAV III APC, LG1 Howitzer (No 3D), M-71

Howitzer (No 3D), M109 Howitzer, M1126 Stryker ICV, M113 APC, M252 Mortar, M270 MLRS, M2A2 Bradley IFV, M3A2

Bradley CFV, M577A2 Command Post, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M993 MLRS, M9 ACE, Mamba APC (No 3D), MO-120RT-61 Mortar, MOWAG Duro (No 3D), MT-LB APC, Namer APC (No 3D), Panhard AML-245 (No 3D),

Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzerhaubitze 2000 Howitzer, Patria AMV (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Puma CEV (No 3D), Rapier SAM (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Type 85 (YW 531H) APC (No 3D), VAB APC, VBCI APC (No 3D), VBL ATV, Wiesel AWC (No

3D), WZ551 APC (No 3D), XM7 FIST-Bradley, ZPU-4 AA Gun,

ZSU-23-4 Shilka


image


Section XIV - Appendixes

D-20 VT MAK


Tracks 2S19 Msta-S (No 3D), Aardvark JSFU (No 3D), Achzarit APC (No 3D), AMX-30D (No 3D), AMX-30 MBT, AMX-56 Leclerc

MBT, Arjun MBT (No 3D), AS-90 Artillery, ASCOD Ulan AIFV (No 3D), ASTROS II MLRS (No 3D), AUF1 155mm Howitzer (No

3D), Badger AEV (No 3D), Bandvagn 206 (No 3D), Beaver AVLB (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP- 1 AFV, BMP-2 AFV, BTR-60 APC, BTR-80 APC, BTR-90, Buffel

ARV (No 3D), C1 Ariete MBT (No 3D), Cougar FSV, Coyote APC (No 3D), CV9035 AFV, DNG/DCL (No 3D), FV 510 Warrior (No

3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Chal- lenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D), Grizzly APC (No 3D), GTK Boxer APC (No 3D), Husky ARV (No 3D), K1A1 MBT (No 3D), LAV III APC, Leopard 2 Tank,

LG1 Howitzer (No 3D), M-71 Howitzer (No 3D), M109 Howitzer, M1A2 Abrams MBT, M252 Mortar, M2A2 Bradley IFV, M3A2 Bradley CFV, M577A2 Command Post, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M993 MLRS, M9 ACE, Mamba APC (No 3D), MBT 2000 (No 3D), Merkava III MBT (No 3D), Merkava IV MBT (No 3D), MT-LB APC, Namer APC (No 3D),

Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panzer- haubitze 2000 Howitzer, Patria AMV (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), PT-91 Twardy MBT (No 3D), Puma CEV (No 3D), Rapier SAM (No 3D), Renault GBC 180 Truck (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Taurus ARV (No 3D), TRM 1000 Truck (No 3D), Type 85 (YW 531H) APC (No 3D), Type 10 MBT

(No 3D), Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), VAB APC, VBL ATV, VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), WZ551 APC (No 3D), XM7 FIST-Bradley, ZSU-

23-4 Shilka

Tracks/Amphib- ious

AAVC7A1 Landing Vehicle


image


No Armor Actros AHSVS (No 3D), Aircraft Baggage Conveyor, Aircraft Baggage Truck, Aircraft Baggage Wagon, Aircraft Catering Truck, Aircraft Follow Me Car, Aircraft High Loader Dolly, Aircraft Mobile Stairs, Aircraft Tow Tractor 1, Aircraft Tow Tractor 2, Aircraft Towbar, Airport Bus, Ambulance, Patriot Radar AN/MPQ-65, Auto Rickshaw, BMW 320D Series, BMW 328i Series, BMW M5 Series, BMW X3 Series, BMW X5 Series, Bulldozer, Bus MBTA, Bus, BV206 SUSV (No 3D), Camel, Car Bomb, Chevrolet Caprice, Chevy Tahoe, Civilian vehicle, CUCV II (No 3D), Defense Satellite, Duffle Bag, Federal Express Truck, Female On Bike, Fenneck, Fiat 124, Fire Engine, Food Truck, Ford Aircraft Oil Truck, Ford Ambulance (Boston), Ford Ambu- lance, Ford Contour, Ford Pickup Truck (White), Ford Pickup Truck (Red), Fuel Tanker Trailer, G-Wagen (No 3D), GAZ-66 Truck, GAZ-69 Utility Vehicle, GMC Yukon, Goat, HMMWV Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Honda Accord (Silver), Honda Accord, Horse, Iveco LMV (No 3D), Jackal MWMIK (No 3D), Jingle Truck, Ladder Truck, Land Rover Wolf (No 3D), Land Rover, LCAC, LIV (SO) Serval (No 3D), M- Gator ATV, M1028 FMTV Cargo Truck, M35 Truck, M58 MICLIC, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, Male On Motorbike, Male On Bike, Mercedes M Series, MILCOTTS Silverado (No 3D), M901 Patriot Launcher, Patriot Air Defense System (PAC-3), Mini Cooper Silver, Mule, Navistar 7000 (No 3D), Nissan Maxima, Nuclear Power Plant, Paddy Wagon, EPP-III Patriot Power Generator, Patriot Engagement Control Sys, Police Car (BMW M5), Police Cruiser (Chevy), Police Paddy Wagon, Police Tactical Van, Police Car (Ford), Pomornik (Zubr)-class LCAC (No 3D), Renault GBC 180 Truck (No 3D), Roadside IED, Safir Military Vehicle, Sheep, Taxicab, Technical Truck, Toyota Corolla, Toyota Pickup, Tractor Trailer Cab, Tractor Trailer with Cab, TRM 1000 Truck (No 3D), URO VAMTAC (No 3D), US Postal Truck, Van (Blue), Van (Green), Van (Red), Van (White), VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), Volkswagen Golf (Black), Volkswagen Golf (White), Volkswagen Passat, Water Buffalo, ZIL-135 8x8 Truck

image


Section XIV - Appendixes

D-22 VT MAK


Wheels (off road) Actros AHSVS (No 3D), AMX-10RC (No 3D), Aravis MRAP (No 3D), ATF Dingo (No 3D), Auverland A4 AVL (No 3D), Buffalo MRAP III, Bushmaster PMV (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Camel, Cow, CUCV II (No 3D), Dardo IFV (No 3D), EE-9 Cascavel (No 3D), ERC 90 Sagaie (No 3D), ESK Mungo (No 3D), Female On Bike, Fenneck, Fire Engine, Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Freccia IFV (No 3D), Fuchs APC (No 3D), GAZ-69 Utility Vehicle, GMC Yukon, Goat, HMMWV Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Horse, Iveco LMV (No 3D), Jackal MWMIK (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LIV (SO) Serval (No 3D), M1126 Stryker ICV, M113 APC, M270 MLRS, M35 Truck, M58 MICLIC, M939A2 5-Ton Truck, M977

HEMTT Cargo Truck, M978 HEMTT Fuel Truck, Male On Motor- bike, Male On Bike, Patriot Air Defense System (PAC-3), MO- 120RT-61 Mortar, MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MRAP-ATV, MRAP-CAT II Cougar, MRAP-CAT I MaxxPro,

Mule, Navistar 7000 (No 3D), Panther CLV (No 3D), EPP-III Patriot Power Generator, Puma AFV (No 3D), RG-31 Nyala (No 3D), SA-9 Gaskin SAM System, Sheep, Technical Truck, URO VAMTAC (No 3D), VBCI APC (No 3D), VM 90 LSVW (No 3D),

Water Buffalo, ZIL-135 8x8 Truck

Wheels (road) Aircraft Baggage Conveyor, Aircraft Baggage Truck, Aircraft Baggage Wagon, Aircraft Catering Truck, Aircraft Follow Me Car, Aircraft High Loader Dolly, Aircraft Mobile Stairs, Aircraft Tow Tractor 1, Aircraft Tow Tractor 2, Aircraft Towbar, Airport Bus, Ambulance, Auto Rickshaw, BMW 320D Series, BMW 328i Series, BMW M5 Series, BMW X3 Series, BMW X5 Series, Bull- dozer, Bus MBTA, Bus, BV206 SUSV (No 3D), Car Bomb, Chev- rolet Caprice, Chevy Tahoe, Civilian vehicle, Federal Express Truck, Fiat 124, Food Truck, Ford Aircraft Oil Truck, Ford Contour, Fuel Tanker Trailer, G-Wagen (No 3D), GAZ-66 Truck, Honda Accord (Silver), Honda Accord, Jingle Truck, Ladder Truck, M-Gator ATV, M1028 FMTV Cargo Truck, Mercedes M Series, MILCOTTS Silverado (No 3D), Mini Cooper Silver, Nissan Maxima, Paddy Wagon, Police Car (BMW M5), Police Cruiser (Chevy), Police Paddy Wagon, Police Tactical Van, Police Car (Ford), Safir Military Vehicle, Taxicab, Toyota Corolla, Toyota Pickup, Tractor Trailer Cab, Tractor Trailer with Cab, US Postal Truck, Van (Blue), Van (Green), Van (Red), Van (White), Volk- swagen Golf (Black), Volkswagen Golf (White), Volkswagen Passat, Wiesel AWC (No 3D)

GSh-301 Cannon AMX (No 3D), Chengdu J-7 (No 3D), Mirage 2000, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Xian H-6 Badger (No 3D)

image


AK-47 Afghan Police Officer, Afghan Soldier, African Insurgent, DI AK- 47, DI Lasing (CIS), Insurgent, Iranian Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Mideast Combatant, Pakistani Police Officer, Pakistani Soldier, Russian Rebels, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier

AT4 Chilean AT4, US Army AT4

Throw Grenades Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Chilean AT4, Chilean IMI Galil, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And

Rifle, European Soldier, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Mideast Combatant, Mideast Combatant with RPG, Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Navy With Binoculars, US Navy, USMC M16, USMC M240, USMC M249, USMC M4, US

Army AT4, US Army Javelin, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9

M16 rifle Border Patrol Agent, Brazilian Soldier, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M4, Colombian Police Officer, Colombian Soldier, DI Lasing (US), DI SMAW And Rifle, Emergency Medical Technician, European Soldier, Ghillie Suit Soldier, Iraqi Police Officer, Iraqi Soldier, Police Officer, Sergeant M16, Suspect, UK Soldier, US Navy With Binoculars, US Navy, USMC M16-M203, USMC M16, USMC M4, US Army M16- M203, US Army M16, US Army M4, US Army M9

Handheld M240B Machine Gun

Chilean M240, USMC M240, US Army M240

M249 SAW Chilean M249, USMC M249, US Army M249

Handheld M60 Machine Gun

Chilean M60, US Army M60

RPG Launcher DI RPG, , Mideast Combatant with RPG, US Army Javelin Handheld UAV Ababil UAV (No 3D), EMT Aladin (No 3D), EMT Luna (No 3D),

Maveric UAS (No 3D), Mohajer UAV (No 3D), RDE KZO (No 3D),

RQ-11 Raven UAV, RQ-7 Shadow UAV (No 3D), ScanEagle UAV (No 3D)

image


Section XIV - Appendixes

D-24 VT MAK


Homing Torpedo Capability (Forward Launched)


Human Disaggre- gated Movement

Admiral Grigorovich-class Frigate (No 3D), Agosta 90B-class Submarine (No 3D), AgustaWestland AW101 (No 3D), Ahmad Yani-class Frigate, Akula-class Submarine (No 3D), Albatros- class Fast Attack (No 3D), Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), Brandenburg-class Frigate (No 3D), Bremen-class Frigate (No 3D), Challenger-class Submarine (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Delta III-class Submarine (No 3D), Delta IV- class Submarine (No 3D), Dolphin-class Submarine (No 3D), Durand de la Penne-class Destroyer (No 3D), F-22P Zulfiquar- class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Flyve- fisken-class Patrol Boat (No 3D), Fridtjof Nansen-class (No 3D), Gepard-class Frigate (No 3D), Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Halifax-class Frigate (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), Iroquois-class Destroyer (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Los Angeles-Class Submarine, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Neustrashimyy-class Frigate (No 3D), Niteroi-class Frigate (No 3D), Ohio-class Submarine, Oscar-class Submarine (No 3D), Pauk-class Corvette (No 3D), Romeo-class Submarine, Rubis-Class Submarine, RUR-5 ASROC, Sachsen-class Frigate (No 3D), Scorpene-class Subma- rine (No 3D), SH-60 Seahawk, Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Trafalgar-class Submarine (No 3D), Triomphant- Class Submarine (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 209 Subma- rine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 23 Frigate, Udaloy-class Destroyer, Ula-class Submarine (No 3D), Vanguard-class Subma- rine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), Walrus-class subma- rine (No 3D), Yuan-class Submarine (No 3D)

COLT Team (CIS), COLT Team (US), DI Plt (CIS), DI Squad (CIS), USMC FT, USMC SQD, US Army LtInf FT, US Army LtInf

SQD, US Army Mech FT A (Javelin), US Army Mech FT B, US Army Mech SQD

Suicide Vest Suicide Bomber

Flee From Explo- sions

Child, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Construction Worker, Female Civilian (Crowd Behavior), Male Civilian (Crowd Behavior), Mideast Female, Mideast Male


image


Human Default Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Cameraman, Chicken, Child, Child (Crowd Behavior), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Colombian Police Officer, Colombian Soldier, Construction Worker, DI AK- 47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, Emergency Medical Technician, European Soldier, Factory Worker, Female Civilian (Crowd Behavior), Female Dancer, Fireman (Extinguisher), Fireman (Hose), Flight Deck Crew, Flight Deck Crewman, Flight Deck Crew (Chock And Chains), Flight Deck Crew (Grounding Cable), Flight Deck Crew (Pallet Handler), Flight Deck Worker, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Male Civilian (Crowd Behavior), Man in Wheelchair, Mideast Combatant, Mideast Combatant with RPG, Mideast Female, Mideast Female (Crowd Behavior), Mideast Male, Mideast Male (Crowd Behavior), Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Army Medic, US EOD, US Navy With Binocu- lars, US Navy, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, Western Teen

image


Section XIV - Appendixes

D-26 VT MAK


IFF Transponder A-10 Thunderbolt, A-4 Skyhawk (No 3D), AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Airbus 310, Airbus 320 - American Airlines, Airbus 320 - British Airways, Airbus 320 - Lufthansa, Airbus 320 - Singapore Airlines, Airbus 380 (No 3D), Albatros-class Fast Attack (No 3D), AMX (No 3D), Antonov-class (No 3D), AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-

365 Dauphin (No 3D), AS-565 Panther (No 3D), Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), AT-802 (No 3D), AV-8B Harrier II, B-2 Spirit, BAE CT-155 Hawk (No 3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Beechcraft 36 Bonanza (No 3D), Beechcraft C-12 Super King (No 3D), Beechcraft T-6 (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), BN-2 Islander (No 3D), Boeing 707, Boeing 737 British Midland, Boeing 747-400, Boeing 757 (No 3D), Boeing 767 (No 3D), Boeing 777 (No 3D), Boeing 787 (No 3D), Bombardier CL-600 (No 3D), Bombardier DHC-8 (No 3D), Sentinel R1 (No 3D), Bombardier CRJ100 Conrad Air, Bombardier CRJ200 Air France, C-130 Hercules, C- 17 Globemaster III (No 3D), C-5 Galaxy (No 3D), Canadair CT- 114 (No 3D), Cape-class Patrol Boat (No 3D), CASA C-212 Aviocar (No 3D), Cessna 172 Skyhawk, Cessna Citation (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chengdu J-7 (No 3D), Cypher VTUAV, Dabur-class Patrol Boat (No 3D), Dassault Atlantic (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), Delhi-class Destroyer (No 3D), Dornier DO 228-200 LGW, Dragon Warrior VTUAV, Durand de la Penne-class Destroyer (No 3D), E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EADS CASA C-295 (No 3D), EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D), EC665

Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo-class Survey Ship (No 3D), EH101 Merlin (No 3D), Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22P Zulfiquar-class Frigate (No 3D), F-22 Raptor (No 3D), F-35 Lightning II, Fatahillah-class Frigate (No 3D), F/A-18 Hornet, Gulfstream G550 (No 3D), Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), HH-65 Dolphin (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), IAI 1124 Sea Scan (No 3D), Il-76 Candid (No 3D), Iroquois- class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), KA- 50 Hokum, KC-135 Stratotanker, KCR-40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Kolkata-class Destroyer (No 3D), L 14 Albion (No 3D), Lockheed L-1011 (No 3D), LPH01 Ocean (No 3D), MD 500 (No 3D), MH-47 Chinook

(No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D)

image


IFF Transponder (continued)

Mi-24 Hind, Mi-28 Havoc, Mi-2 Hoplite, MiG-27 Flogger, MiG-29 Fulcrum, Milgem Class Corvette, Mirage 2000, Mirage F1, Murasame-class Destroyer (No 3D), Nanchang Q-5 (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, OH-58 Kiowa, P-3 Orion, RAH-66 Comanche, River-class Patrol Vessel (No 3D), SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Sovremennyy-class Destroyer, Space Shuttle, SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy- class Destroyer, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), Ultralight Trike, V-22 Osprey (No 3D), Victory-class Corvette (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)

IR Sensor AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Antonov-class (No 3D), Arleigh Burke-class Destroyer, AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Dabur- class Patrol Boat (No 3D), EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo-class Survey Ship (No 3D), EH101 Merlin (No 3D), Hermes 450 (No 3D), HH-65 Dolphin (No 3D), HMMWV with Avenger, Holland Class OPV (No 3D), Il-76 Candid (No 3D), Island-class Patrol Vessel (No 3D), KA-50 Hokum, Kirov-class Guided Missile Cruiser (No 3D), Maveric UAS (No 3D), MD 500 (No 3D), MH-47 Chinook (No 3D), MH-

60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi- 2 Hoplite, Mistral Class AAS (No 3D), MQ-4C Triton, MQ-8B Fire Scout, MQ-9 Reaper UAV, NH90-N1 (No 3D), OH-58 Kiowa, MQ-1 Predator, RAH-66 Comanche, RDE KZO (No 3D), River-class Patrol Vessel (No 3D), RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SAGEM Sperwer (No 3D), Sandown-class Minehunter (No 3D), ScanEagle UAV (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Slava-class Guided Missile Cruiser (No 3D), Type 42 Destroyer (No 3D), UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D)

Laser Designator DI Lasing (CIS), DI Lasing (US)

image


Section XIV - Appendixes

D-28 VT MAK


Hydra 70 APKWS Launcher

Laser Guided Hell- fire Missile Launcher


Laser Guided Missile Dynamics

MQ-8B Fire Scout


AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), EC665 Eurocopter Tiger (No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MQ-9 Reaper UAV, NH90-N1 (No 3D),

RAH-66 Comanche

Hydra-70, Laser Guided Hellfire Missile

Default Armor Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Cameraman, Chicken, Child, Child (Crowd Behavior), Child (Injured), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Colombian Police Officer, Colombian Soldier, Construction Worker, Cow, DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, Emergency Medical Technician, Euro- pean Soldier, Factory Worker, Female Civilian (Crowd Behavior), Female Dancer, Fireman (Extinguisher), Fireman (Hose), Flight Deck Crew, Flight Deck Crewman, Flight Deck Crew (Chock And Chains), Flight Deck Crew (Grounding Cable), Flight Deck Crew (Pallet Handler), Flight Deck Worker, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Male Civilian (Crowd Behavior), Man in Wheelchair, Mideast Combatant, Mideast Combatant with RPG, Mideast Female, Mideast Female (Crowd Behavior), Mideast Male, Mideast Male (Crowd Behavior), Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army

Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, Western Teen

image


Lifeform Suppres- sion


Limit Entity Exis- tence

M1A2 Main Gun and MGs

M2HB Machine Gun

Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Cameraman, Child, Child (Crowd Behavior), Child (Injured), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Colombian Police Officer, Colombian Soldier, Construction Worker, DI AK- 47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, Emergency Medical Technician, European Soldier, Factory Worker, Female Civilian (Crowd Behavior), Female Dancer, Fireman (Extinguisher), Fireman (Hose), Flight Deck Crew, Flight Deck Crewman, Flight Deck Crew (Chock And Chains), Flight Deck Crew (Grounding Cable), Flight Deck Crew (Pallet Handler), Flight Deck Worker, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Male Civilian (Crowd Behavior), Man in Wheelchair, Mideast Combatant, Mideast Combatant with RPG, Mideast Female, Mideast Female (Crowd Behavior), Mideast Male, Mideast Male (Crowd Behavior), Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Army Medic, US EOD, US Navy With Binocu- lars, US Navy, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, Western Teen

CIS Chaff, CIS Flare, Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, RUR-5 ASROC, US Chaff, US Flare

M1A2 Abrams MBT


2S19 Msta-S (No 3D), Achzarit APC (No 3D), AMX-10RC (No

3D), AMX-30D (No 3D), Aravis MRAP (No 3D), ASTROS II

MLRS (No 3D), Auverland A4 AVL (No 3D), Badger AEV (No 3D), Bergepanzer 2 ARV (No 3D), BTR-60 APC, Buffel ARV (No 3D), DNG/DCL (No 3D), ERC 90 Sagaie (No 3D), Fenneck, LCS

Freedom Class (No 3D), GTK Boxer APC (No 3D), HMMWV with M2, LCS Independence Class (No 3D), Leopard 2 Tank, LIV (SO) Serval (No 3D), M1126 Stryker ICV, M113 APC, MT-LB APC,

Namer APC (No 3D), PLZ-45 Howitzer (No 3D), Rigid-Hulled Inflatable Boat, Taurus ARV (No 3D), Technical Truck, Type 85 (YW 531H) APC (No 3D), Type 10 MBT (No 3D), Type 90 Kyu-

maru MBT (No 3D), National Security Cutter, VAB APC, VBCI APC (No 3D), Marine Protector Class Patrol Boat, WZ551 APC (No 3D)


image


Section XIV - Appendixes

D-30 VT MAK


M203 Grenade Launcher

Chilean M16-M203, USMC M16-M203, US Army M16-M203

M230 Chain Gun AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), MH-60L Black Hawk DAP (No 3D), RAH-66 Comanche, West- land Lynx (No 3D)

M240 Machine Gun


M250 smoke grenade launcher


M252 81mm

mortar

M270 MLRS

Launcher

M284 155mm

Cannon


M60 Machine Gun

AAVC7A1 Landing Vehicle, Arjun MBT (No 3D), AS 550 Fennec (No 3D), ASCOD Ulan AIFV (No 3D), ATF Dingo (No 3D), Bison APC (No 3D), BTR-80 APC, BTR-90, C1 Ariete MBT (No 3D),

Cadillac Gage Commando V-150 (No 3D), Centauro B1 (No 3D), Cougar FSV, CV9035 AFV, Dardo IFV (No 3D), EE-9 Cascavel (No 3D), Freccia IFV (No 3D), Fuchs APC (No 3D), FV4034

Challenger 2 MBT (No 3D), FV432 APC (No 3D), Grizzly APC (No 3D), HH-65 Dolphin (No 3D), Husky ARV (No 3D), Iveco LMV (No 3D), Jackal MWMIK (No 3D), LAPV Enok (No 3D), LAV III APC, LIV (SO) Serval (No 3D), Mamba APC (No 3D), MBT 2000 (No 3D), MH-47 Chinook (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MRAP-ATV, MRAP-CAT II Cougar,

MRAP-CAT I MaxxPro, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panzerhaubitze 2000 Howitzer, Patria AMV (No 3D), Pegaso 3046 APC (No 3D), PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), RG-31 Nyala (No 3D), T-84 MBT (No 3D), T90A MBT (No 3D), Type 99 MBT (No 3D), V-22 Osprey (No 3D), VM 90 LSVW (No 3D), WZ551 APC (No 3D)

Achzarit APC (No 3D), AMX-10RC (No 3D), Arjun MBT (No 3D),

Badger AEV (No 3D), Bandvagn 206 (No 3D), Bergepanzer 2 ARV (No 3D), Buffel ARV (No 3D), CV9035 AFV, EE-9 Cascavel (No 3D), ERC 90 Sagaie (No 3D), Fuchs APC (No 3D), M1A2

Abrams MBT, Merkava III MBT (No 3D), Merkava IV MBT (No 3D), Namer APC (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), Taurus ARV (No 3D), Type 10 MBT (No 3D)

M252 Mortar


ASTROS II MLRS (No 3D), M270 MLRS, M993 MLRS


2S19 Msta-S (No 3D), AS-90 Artillery, AUF1 155mm Howitzer (No 3D), CAESAR SP Howitzer, L-118 Howitzer (No 3D), LG1 Howitzer (No 3D), M-71 Howitzer (No 3D), M109 Howitzer, M777 Howitzer (No 3D), Panzerhaubitze 2000 Howitzer, PLZ-45 Howitzer (No 3D), URO VAMTAC (No 3D)

CH-148 Cyclone (No 3D), CH-47 Chinook (No 3D), MH-60 Black Hawk, SH-3 Sea King (No 3D)

M61 Vulcan AMX (No 3D), F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F/A-18 Hornet

MAD Sensor CH-46E Sea Knight, Dassault Atlantic (No 3D), Harbin SH-5 ASW (No 3D), P-3 Orion, SH-60 Seahawk

image


Missile Default Armor


Guided Missile Dynamics

AA-11 Archer Missile, AA-8 Aphid Missile, AGM-65 Maverick Missile, AIM-9 Sidewinder Missile, AS-12 Kegler Missile, AS-14 Kedge Missile, AS-7 Kerry Missile, AT-6 Spiral Missile, BGM-71 TOW Missile, Exocet Cruise Missile, FIM-92 Stinger Missile, Hellfire Missile, Hydra-70, Laser Guided Hellfire Missile, M39 Missile, MIM 104C PAC-3 Patriot Missile, Mistral SAM Missile (No 3D), RUR-5 ASROC, SA-9 Missile, Scud-B Missile, SM-2 Standard Missile, SS-24 Scalpel Missile, SS-24 Scalpel Stage

AA-11 Archer Missile, AA-8 Aphid Missile, AGM-65 Maverick Missile, AIM-9 Sidewinder Missile, AS-12 Kegler Missile, AS-14 Kedge Missile, AS-7 Kerry Missile, AT-6 Spiral Missile, BGM-71 TOW Missile, Exocet Cruise Missile, FIM-92 Stinger Missile, Hellfire Missile, Hydra-70, Laser Guided Hellfire Missile, MIM 104C PAC-3 Patriot Missile, Mistral SAM Missile (No 3D), RUR- 5 ASROC, SA-9 Missile, SM-2 Standard Missile

Missile Warhead 76mm Shell, Ababil UAV (No 3D), Agosta 90B-class Submarine (No 3D), Delta III-class Submarine (No 3D), Delta IV-class Submarine (No 3D), Exocet Cruise Missile, M107 155mm, M26 Rocket, M374A2 81mm, M433, M583A1, M651, M713,

M715, M716, Oscar-class Submarine (No 3D), Rubis-Class Submarine, SM-2 Standard Missile, Triomphant-Class Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Yuan-class Submarine (No 3D)

MK 45 Naval Gun Arleigh Burke-class Destroyer, Bay-class DLS (No 3D), Dabur- class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), Echo-class Survey Ship (No 3D), Guided Missile Destroyer, Halifax-class Frigate (No 3D), Hauk-class Fast Attack (No 3D), Hunt-class Minehunter (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Kingston-class Patrol vessel, L 14 Albion (No 3D), Legend Class (WMSL), LPH01 Ocean (No 3D), Milgem Class Corvette, Oksoy-class Minehunter (No 3D), River-class Patrol Vessel (No 3D), Saar 4- class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Skjold-class Patrol (No 3D), Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Super Dvora Mark II (No 3D), Tiger-class Fast Attack Craft (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Hamilton Class Cutter WHEC

Naval Depth Charge Deploy- ment

B-2 Spirit, Dassault Atlantic (No 3D), Harbin SH-5 ASW (No 3D), P-3 Orion


image


Section XIV - Appendixes

D-32 VT MAK


Naval Mine Deployment


Naval Mine Dynamics

Naval Mine Explo- sive Device

Naval Mine Sweep


Other Explosive Device

B-2 Spirit, Braunschweig-class Corvette (No 3D), Dassault Atlantic (No 3D), Durand de la Penne-class Destroyer (No 3D), Frankenthal-class Minehunter (No 3D), Gaeta-class Minehunter, Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), Kilo-class Submarine (No 3D), Milgem Class Corvette, Osprey-class Mine CMS (No 3D), P- 3 Orion, Runnymede-class Landing Craft Utility 2000 (No 3D), Sandown-class Minehunter (No 3D), Skjold-class Patrol (No 3D), Sovremennyy-class Destroyer, Tiger-class Fast Attack Craft (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate

Naval Mine, Quickstrike Mk 65, Sea Lance ASW Naval Mine, Quickstrike Mk 65, Sea Lance ASW

Alta-class Minehunter (No 3D), Gaeta-class Minehunter, Hunt- class Minehunter (No 3D), Kingston-class Patrol vessel, Osprey- class Mine CMS (No 3D), Oksoy-class Minehunter (No 3D), Sandown-class Minehunter (No 3D), Tiger-class Fast Attack Craft (No 3D)


image


Passive RADAR Sensor


Passive SONAR Sensor


Patriot Missile Launcher

Pedestrian Crowd Movement

Pedestrian Traffic Generator

Ahmad Yani-class Frigate, Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Bay-class Patrol Boat (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Cape-class Patrol Boat (No 3D), Dabur-class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Echo-class Survey Ship (No 3D), Eridan- class Minehunter (No 3D), Floreal-class Frigate (No 3D), Flyve- fisken-class Patrol Boat (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Holland Class OPV (No 3D), Hunt- class Minehunter (No 3D), LCS Independence Class (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Khareff-class Corvette (No 3D), Kirov-class Guided Missile Cruiser (No 3D), La Fayette-class Frigate (No 3D), Lupo-class Frigate (No 3D), M270 MLRS, Maes- trale-class Frigate (No 3D), Mistral Class AAS (No 3D), Niteroi- class Frigate (No 3D), Rapier SAM (No 3D), River-class Patrol Vessel (No 3D), Rubis-Class Submarine, SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Sachsen-class Frigate (No 3D), Sandown-class Minehunter (No 3D), Scorpene-class Submarine (No 3D), Sigma 9113-class Frigate, Slava-class Guided Missile Cruiser (No 3D), Super Tanker, Triomphant-Class Submarine (No 3D), Type 209 Subma- rine (No 3D), Type 23 Frigate, Vanguard-class Submarine (No 3D), Victoria-class (No 3D), Marine Protector Class Patrol Boat

Akula-class Submarine (No 3D), Aquitaine-class Frigate (No 3D), Brandenburg-class Frigate (No 3D), De Zeven Provincien Class Frigate (No 3D), Eridan-class Minehunter (No 3D), Fridtjof Nansen-class (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), Kilo-class Submarine (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Niteroi-class Frigate (No 3D), Oksoy-class Mine- hunter (No 3D), Sonobuoy (Passive), Steregushchiy-class Frigate (No 3D), National Security Cutter, Hamilton Class Cutter WHEC, Victor II-class Submarine (No 3D)

M901 Patriot Launcher, Patriot Air Defense System (PAC-3)


Civilian Crowd (Large), Civilian Crowd (Medium), Civilian Crowd (Small), Civilian Crowd

Civilian Crowd (Large), Civilian Crowd (Medium), Civilian Crowd (Small), Civilian Crowd, Pedestrian Area


image


Section XIV - Appendixes

D-34 VT MAK


Periscope Agosta 90B-class Submarine (No 3D), Akula-class Submarine (No 3D), Astute-class Submarine (No 3D), Challenger-class Submarine (No 3D), Delta III-class Submarine (No 3D), Delta IV- class Submarine (No 3D), Dolphin-class Submarine (No 3D), Gotland-class Submarine (No 3D), Kilo-class Submarine (No 3D), Los Angeles-Class Submarine, Ohio-class Submarine, Oscar- class Submarine (No 3D), Romeo-class Submarine, Rubis-Class Submarine, Scorpene-class Submarine (No 3D), Siera II-class Submarine (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Ula-class Submarine (No 3D), Vanguard-class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Walrus-class submarine (No 3D), Yuan-class Submarine (No 3D)

Rotary Wing Attack


Rotary Wing Default Armor

AH-1W SuperCobra, AH-64A Apache, AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), HH-65 Dolphin (No 3D), KA-50 Hokum, Mi-24 Hind, Mi-28 Havoc, RAH-66 Comanche, SA 342 Gazelle (No 3D)

AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), AirMule, Antonov-class (No 3D), AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365

Dauphin (No 3D), AS-565 Panther (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Cypher VTUAV, DJI S1000, Dragon Warrior VTUAV, EC 135 (No 3D), EC 635 (No

3D), EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), EH101 Merlin (No 3D), HH-65 Dolphin (No 3D), Il-76 Candid (No 3D), KA-50 Hokum, MD 500 (No 3D), MH-47

Chinook (No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi-2 Hoplite, MQ-8B Fire Scout, NH90-N1 (No 3D), OH-58 Kiowa, Quadcopter, RAH-66 Comanche, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, UH-1N Twin Huey (No 3D), UH-60 Black- hawk, UH-72 Lakota (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D)

Cargo AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), Antonov-class (No 3D), AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), CH-148 Cyclone (No 3D), CH-47 Chinook (No 3D), CH-53E Super Stallion, EH101 Merlin (No 3D), Il-76 Candid (No 3D), MH-47 Chinook (No 3D), SA 330 Puma (No 3D), SH-3 Sea King (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D)

image


Quadcopter Heavy Lift

AirMule

Quadcopter DJI S1000, Quadcopter

Dipping SONAR Sensor

CH-46E Sea Knight, NH90-N1 (No 3D), SH-3 Sea King (No 3D),

SH-60 Seahawk

Utility AH-6 Little Bird (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), CH-149 Cormorant, CH-46E Sea Knight, EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D), MD 500 (No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black

Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-2 Hoplite, MQ-8B Fire Scout, NH90-N1 (No 3D), OH-58 Kiowa, SH-60 Seahawk, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D)

VTUAV Cypher VTUAV, Dragon Warrior VTUAV

SA-9 SAM Missile Launcher

Scripted Move- ment

Rapier SAM (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System

M39 Missile, Scud-B Missile, SS-24 Scalpel Missile, SS-24 Scalpel Stage

Small boat Albatros-class Fast Attack (No 3D), Bay-class Patrol Boat (No 3D), Cape-class Patrol Boat (No 3D), Dabur-class Patrol Boat (No 3D), Echo-class Survey Ship (No 3D), Fleet-class USV (No 3D), Grisha-class Corvette (No 3D), Hamina-class Fast Attack (No 3D), Hauk-class Fast Attack (No 3D), Holland Class OPV (No 3D), Island-class Patrol Vessel (No 3D), Jacinto-class Corvette (No 3D), Jet Ski, KAAN 19 Class Fast Patrol Craft, KCR-40 Clurit-class Fast Attack (No 3D), Nanuchka III-class (No 3D), Pauk-class Corvette (No 3D), Rigid-Hulled Inflatable Boat, Rigid- Hulled Inflatable Boat - Civilian, River-class Patrol Vessel (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sailboat, Skiff (Green), Skiff, Skjold-class Patrol (No 3D), Speedboat, Steregus- hchiy-class Frigate (No 3D), Super Dvora Mark II (No 3D), Tarantul-class Corvette (No 3D), Tiara 3900 Yacht, Tiger-class Fast Attack Craft (No 3D)

Bomb Dynamics CBU-105 SFW, GBU-31A JDAM, KAB-500N Bomb

image


Section XIV - Appendixes

D-36 VT MAK


SONAR Sensor Agosta 90B-class Submarine (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Alta-class Mine- hunter (No 3D), AN/BLQ-11 UUV (No 3D), Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), Bay-class DLS (No 3D), Brandenburg-class Frigate (No 3D), Bremen-class Frigate (No 3D), CH-46E Sea Knight, Challenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Delta III- class Submarine (No 3D), Delta IV-class Submarine (No 3D), Dolphin-class Submarine (No 3D), Durand de la Penne-class Destroyer (No 3D), Eridan-class Minehunter (No 3D), Fatahillah- class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), Fridtjof Nansen-class (No 3D), Gaeta-class Minehunter, Gepard-class Frigate (No 3D), Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehu- nter (No 3D), Iroquois-class Destroyer (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov- class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Milgem Class Corvette, Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Murasame-class Destroyer (No 3D), Neustrashimyy-class Frigate (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), Ohio-class Submarine, Oksoy-class Minehunter (No 3D), Oscar-class Submarine (No 3D), Pauk-class Corvette (No 3D), REMUS UUV, Romeo-class Submarine, Rubis-Class Submarine, Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sandown-class Minehunter (No 3D), Scorpene- class Submarine (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Song- class Submarine, Sonobuoy (Passive), Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Ula- class Submarine (No 3D), National Security Cutter, Hamilton Class Cutter WHEC, Victor II-class Submarine (No 3D), Victoria- class (No 3D), Victory-class Corvette (No 3D), Marine Protector Class Patrol Boat

image


SONAR Sensor (continued)

Sonobuoy Deployer

Yuan-class Submarine (No 3D)


Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Cape- class Patrol Boat (No 3D), Dabur-class Patrol Boat (No 3D), Dassault Atlantic (No 3D), Echo-class Survey Ship (No 3D), F- 22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Halifax-class Frigate (No 3D), Harbin SH-5 ASW (No 3D), Horizon-class Destroyer (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), L 14 Albion (No 3D), LPH01 Ocean (No 3D), Milgem Class Corvette, P-3 Orion, River- class Patrol Vessel (No 3D), Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Victory-class Corvette (No 3D)

Space Shuttle Space Shuttle

image


Section XIV - Appendixes

D-38 VT MAK


Spot Report Generator

2S19 Msta-S (No 3D), A-10 Thunderbolt, A-4 Skyhawk (No 3D), Aardvark JSFU (No 3D), AAVC7A1 Landing Vehicle, Ababil UAV (No 3D), Achzarit APC (No 3D), Actros AHSVS (No 3D), Admiral Grigorovich-class Frigate (No 3D), Afghan Police Officer, Afghan Soldier, African Insurgent, Agosta 90B-class Submarine (No 3D), AgustaWestland AW101 (No 3D), Agust- aWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Albatros-class Fast Attack (No 3D), AMX (No 3D), AMX-10RC (No 3D), AMX- 30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT, Antonov-

class (No 3D), AN/BLQ-11 UUV (No 3D), Patriot Radar AN/MPQ- 65, Aquitaine-class Frigate (No 3D), Aravis MRAP (No 3D), Arjun MBT (No 3D), Arleigh Burke-class Destroyer, AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), AS-90 Artillery, ASCOD Ulan AIFV (No 3D), ASTROS II MLRS

(No 3D), ATF Dingo (No 3D), AUF1 155mm Howitzer (No 3D), Auverland A4 AVL (No 3D), AV-8B Harrier II, B-2 Spirit, Badger AEV (No 3D), BAE CT-155 Hawk (No 3D), Bandvagn 206 (No

3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Beaver AVLB (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, BN-2 Islander (No 3D),

Border Patrol Agent, Brandenburg-class Frigate (No 3D), Braun- schweig-class Corvette (No 3D), Brazilian Soldier, Bremen-class Frigate (No 3D), BTR-60 APC, BTR-80 APC, BTR-90, Buffalo

MRAP III, Buffel ARV (No 3D), Bushmaster PMV (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), C1 Ariete MBT (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Canadair CT-114 (No 3D), Cape-class Patrol Boat (No 3D), Centauro B1 (No 3D), Cessna Citation (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chal- lenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), Chengdu J-7 (No 3D), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, Cougar FSV, Coyote APC (No 3D), CUCV II (No 3D), CV9035 AFV, Cypher VTUAV, Dabur-class Patrol Boat (No 3D), Dardo IFV (No 3D), Dassault Atlantic (No 3D), Dassault Mystere- Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), De Zeven Provincien Class Frigate (No 3D), Defense Satellite, Delta III-class Submarine (No 3D), Delta IV-class Submarine (No 3D), DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW

And Rifle, DNG/DCL (No 3D), Dolphin-class Submarine (No 3D)


image


Spot Report Generator

Dragon Warrior VTUAV, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D),

EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo- class Survey Ship (No 3D), EE-9 Cascavel (No 3D), EH101 Merlin (No 3D), Emergency Medical Technician, EMT Aladin (No 3D), EMT Luna (No 3D), ERC 90 Sagaie (No 3D), Eridan-class Minehunter (No 3D), ESK Mungo (No 3D), Eurofighter Typhoon, European Soldier, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22P Zulfiquar-class Frigate (No 3D), F-22 Raptor (No 3D), F-35 Lightning II, Fatahillah-class Frigate (No 3D), Fenneck, Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Franken- thal-class Minehunter (No 3D), Freccia IFV (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Fuchs APC (No 3D), FV 510 Warrior (No 3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D), F/A-18 Hornet, GAZ-69

Utility Vehicle, Gepard-class Frigate (No 3D), Ghillie Suit Soldier, GMC Yukon, Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Grizzly APC (No 3D), GTK Boxer APC (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), Hermes 450 (No 3D), HH-65 Dolphin (No 3D), HMMWV

Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Holland Class OPV (No 3D), Husky ARV (No 3D), Il-76 Candid (No 3D), LCS Independence Class (No 3D), Insurgent, Invincible-class Carrier (No 3D), Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, Iroquois-class Destroyer (No 3D), ISIS Fighter, Island-class Patrol Vessel (No 3D), Iveco LMV (No 3D), Jacinto-class Corvette (No 3D), Jackal MWMIK (No 3D), L-class Frigate (No 3D), K1A1 MBT (No 3D), KA-50 Hokum, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR-40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kurdish Fighter, Kuznetsov-class (No 3D), L 14 Albion (No 3D), L-118 Howitzer (No 3D), La Fayette-class Frigate (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LAV III APC, LCAC, Legend Class (WMSL),

Leopard 2 Tank, LG1 Howitzer (No 3D), Libyan Police Officer, Libyan Soldier, LIV (SO) Serval (No 3D), Lockheed L-1011 (No 3D), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D)


image


Section XIV - Appendixes

D-40 VT MAK


Spot Report Generator

M-71 Howitzer (No 3D), M109 Howitzer, M1126 Stryker ICV, M113 APC, M1A2 Abrams MBT, M270 MLRS, M2A2 Bradley

IFV, M35 Truck, M3A2 Bradley CFV, M577A2 Command Post, M58 MICLIC, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, M993 MLRS, M9 ACE, Maestrale- class Frigate (No 3D), Mamba APC (No 3D), Maveric UAS (No 3D), MBT 2000 (No 3D), MD 500 (No 3D), Merkava III MBT (No

3D), Merkava IV MBT (No 3D), MH-47 Chinook (No 3D), MH- 60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi- 2 Hoplite, Mideast Combatant, Mideast Combatant with RPG, MiG-27 Flogger, MiG-29 Fulcrum, Milgem Class Corvette, M901 Patriot Launcher, Patriot Air Defense System (PAC-3), Mirage 2000, Mirage F1, Mistral Class AAS (No 3D), MO-120RT-61 Mortar, Mohajer UAV (No 3D), Moudge-class Frigate (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MQ-4C Triton, MQ-8B Fire Scout, MQ-9 Reaper UAV, MRAP-ATV, MRAP-CAT

II Cougar, MRAP-CAT I MaxxPro, MT-LB APC, Namer APC (No 3D), Nanchang Q-5 (No 3D), Nanuchka III-class (No 3D), Navistar 7000 (No 3D), Neustrashimyy-class Frigate (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), OH-58 Kiowa, Ohio-class Submarine, Oksoy-class Minehu- nter (No 3D), Oscar-class Submarine (No 3D), P-3 Orion, Paki- stani Police Officer, Pakistani Soldier, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzer- haubitze 2000 Howitzer, Patria AMV (No 3D), EPP-III Patriot Power Generator, Patriot Engagement Control Sys, Pauk-class Corvette (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Police Officer, Pomornik (Zubr)-class LCAC (No 3D), MQ-1 Predator, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), Queen Elizabeth-class Carrier (No 3D), RAH-66 Comanche, Rapier SAM (No 3D), RDE KZO (No 3D), REMUS UUV, Renault GBC 180 Truck (No 3D), RG-31 Nyala (No 3D), Rigid-Hulled Inflatable Boat, River-class Patrol Vessel (No 3D), Romeo-class Submarine, RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), Rubis-Class Subma- rine, Russian Rebels, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Scorpene-class Submarine (No 3D), Sentinel-class (WPC) (No 3D), Sergeant M16, SH-3 Sea King (No 3D), SH-60 Seahawk, Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Somali Police Officer


image


Spot Report Generator (continued)

Somali Soldier, Song-class Submarine, Sonobuoy (Passive), Sovremennyy-class Destroyer, Space Shuttle, Steregushchiy- class Frigate (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Sudanese Police Officer, Sudanese Soldier, Super Dvora Mark II (No 3D), Suspect, Syrian Police Officer, Syrian Soldier, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A

MBT (No 3D), Taliban, Tarantul-class Corvette (No 3D), Taurus ARV (No 3D), Technical Truck, Tiger-class Fast Attack Craft (No 3D), Tornado ADV (No 3D), Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), TRM 1000 Truck (No 3D), Tu-160 Blackjack (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 85 (YW 531H) APC (No 3D), Type 45 Destroyer, Type 10 MBT (No 3D), Type 22 Frigate (No 3D), Type 23 Frigate, Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), Udaloy-class Destroyer, Ugandan Police Officer, Ugandan Soldier, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), UK Soldier, Ula-class Submarine (No 3D), URO VAMTAC (No 3D), US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, National Security Cutter, Hamilton Class Cutter WHEC, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, V-22 Osprey (No 3D), VAB APC, Vanguard-class Submarine (No 3D), VBCI APC (No 3D), VBL ATV, Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), VM 90 LSVW (No

3D), Walrus-class submarine (No 3D), Westland Lynx (No 3D), Wiesel AWC (No 3D), Marine Protector Class Patrol Boat, WS- 61 Sea King (No 3D), WZ551 APC (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D), XM7 FIST-Bradley, Yuan-class Submarine (No 3D), ZIL-135 8x8 Truck, ZPU-4 AA Gun, ZSU- 23-4 Shilka


image


Section XIV - Appendixes

D-42 VT MAK


Spot Report Receiver

2S19 Msta-S (No 3D), A-10 Thunderbolt, A-4 Skyhawk (No 3D), Aardvark JSFU (No 3D), AAVC7A1 Landing Vehicle, Ababil UAV (No 3D), Achzarit APC (No 3D), Actros AHSVS (No 3D), Admiral Grigorovich-class Frigate (No 3D), Afghan Police Officer, Afghan Soldier, African Insurgent, Agosta 90B-class Submarine (No 3D), AgustaWestland AW101 (No 3D), Agust- aWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Albatros-class Fast Attack (No 3D), AMX (No 3D), AMX-10RC (No 3D), AMX- 30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT, Antonov-

class (No 3D), AN/BLQ-11 UUV (No 3D), Patriot Radar AN/MPQ- 65, Aquitaine-class Frigate (No 3D), Aravis MRAP (No 3D), Arjun MBT (No 3D), Arleigh Burke-class Destroyer, AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), AS-90 Artillery, ASCOD Ulan AIFV (No 3D), ASTROS II MLRS

(No 3D), ATF Dingo (No 3D), AUF1 155mm Howitzer (No 3D), Auverland A4 AVL (No 3D), AV-8B Harrier II, B-2 Spirit, Badger AEV (No 3D), BAE CT-155 Hawk (No 3D), Bandvagn 206 (No

3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Beaver AVLB (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, BN-2 Islander (No 3D),

Border Patrol Agent, Brandenburg-class Frigate (No 3D), Braun- schweig-class Corvette (No 3D), Brazilian Soldier, Bremen-class Frigate (No 3D), BTR-60 APC, BTR-80 APC, BTR-90, Buffalo

MRAP III, Buffel ARV (No 3D), Bushmaster PMV (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), C1 Ariete MBT (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Canadair CT-114 (No 3D), Cape-class Patrol Boat (No 3D), Centauro B1 (No 3D), Cessna Citation (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chal- lenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), Chengdu J-7 (No 3D), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, Cougar FSV, Coyote APC (No 3D), CUCV II (No 3D), CV9035 AFV, Dabur-class Patrol Boat (No 3D), Dardo IFV (No 3D), Dassault Atlantic (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), De Zeven Provincien Class Frigate (No 3D), Defense Satellite, Delta III-class Subma- rine (No 3D), Delta IV-class Submarine (No 3D), DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, DNG/DCL (No 3D), Dolphin-class Submarine (No 3D), E-2 Hawkeye


image


Spot Report Receiver

E-3 Sentry, EA-6B Prowler, EC 135 (No 3D), EC 635 (No 3D),

EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo-class Survey Ship (No 3D), EE-9 Cascavel (No 3D), EH101 Merlin (No 3D), Emergency Medical Technician, EMT Aladin (No 3D), EMT Luna (No 3D), ERC 90 Sagaie (No 3D), Eridan-class Minehunter (No 3D), ESK Mungo (No 3D), Eurofighter Typhoon, European Soldier, F-117A Nighthawk, F- 15 Eagle, F-16A Fighting Falcon, F-22P Zulfiquar-class Frigate (No 3D), F-22 Raptor (No 3D), F-35 Lightning II, Fatahillah-class Frigate (No 3D), Fenneck, Floreal-class Frigate (No 3D), Flyve- fisken-class Patrol Boat (No 3D), Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Frankenthal-class Minehunter (No 3D), Freccia IFV (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Fuchs APC (No 3D), FV 510 Warrior (No 3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D), F/A-18 Hornet, GAZ-69

Utility Vehicle, Gepard-class Frigate (No 3D), Ghillie Suit Soldier, GMC Yukon, Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Grizzly APC (No 3D), GTK Boxer APC (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), Hermes 450 (No 3D), HH-65 Dolphin (No 3D), HMMWV

Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Holland Class OPV (No 3D), Husky ARV (No 3D), Il-76 Candid (No 3D), LCS Independence Class (No 3D), Insurgent, Invincible-class Carrier (No 3D), Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, Iroquois-class Destroyer (No 3D), ISIS Fighter, Island-class Patrol Vessel (No 3D), Iveco LMV (No 3D), Jacinto-class Corvette (No 3D), Jackal MWMIK (No 3D), L-class Frigate (No 3D), K1A1 MBT (No 3D), KA-50 Hokum, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR-40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kurdish Fighter, Kuznetsov-class (No 3D), L 14 Albion (No 3D), L-118 Howitzer (No 3D), La Fayette-class Frigate (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LAV III APC, LCAC, Legend Class (WMSL),

Leopard 2 Tank, LG1 Howitzer (No 3D), Libyan Police Officer, Libyan Soldier, LIV (SO) Serval (No 3D), Lockheed L-1011 (No 3D), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), M-71 Howitzer (No 3D), M109 Howitzer, M1126 Stryker ICV


image


Section XIV - Appendixes

D-44 VT MAK


Spot Report Receiver

M113 APC, M1A2 Abrams MBT, M270 MLRS, M2A2 Bradley

IFV, M35 Truck, M3A2 Bradley CFV, M577A2 Command Post, M58 MICLIC, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, M993 MLRS, M9 ACE, Maestrale- class Frigate (No 3D), Mamba APC (No 3D), Maveric UAS (No 3D), MBT 2000 (No 3D), MD 500 (No 3D), Merkava III MBT (No

3D), Merkava IV MBT (No 3D), MH-47 Chinook (No 3D), MH- 60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi- 2 Hoplite, Mideast Combatant, Mideast Combatant with RPG, MiG-27 Flogger, MiG-29 Fulcrum, Milgem Class Corvette, M901 Patriot Launcher, Patriot Air Defense System (PAC-3), Mirage 2000, Mirage F1, Mistral Class AAS (No 3D), MO-120RT-61 Mortar, Mohajer UAV (No 3D), Moudge-class Frigate (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MQ-4C Triton, MQ-8B Fire Scout, MQ-9 Reaper UAV, MRAP-ATV, MRAP-CAT

II Cougar, MRAP-CAT I MaxxPro, MT-LB APC, Namer APC (No 3D), Nanchang Q-5 (No 3D), Nanuchka III-class (No 3D), Navistar 7000 (No 3D), Neustrashimyy-class Frigate (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), OH-58 Kiowa, Ohio-class Submarine, Oksoy-class Minehu- nter (No 3D), Oscar-class Submarine (No 3D), P-3 Orion, Paki- stani Police Officer, Pakistani Soldier, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzer- haubitze 2000 Howitzer, Patria AMV (No 3D), EPP-III Patriot Power Generator, Patriot Engagement Control Sys, Pauk-class Corvette (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Police Officer, Pomornik (Zubr)-class LCAC (No 3D), MQ-1 Predator, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), Queen Elizabeth-class Carrier (No 3D), RAH-66 Comanche, Rapier SAM (No 3D), RDE KZO (No 3D), REMUS UUV, Renault GBC 180 Truck (No 3D), RG-31 Nyala (No 3D), Rigid-Hulled Inflatable Boat, River-class Patrol Vessel (No 3D), Romeo-class Submarine, RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), Rubis-Class Subma- rine, Russian Rebels, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Sachsen-class Frigate (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Scorpene- class Submarine (No 3D), Sentinel-class (WPC) (No 3D), Sergeant M16, SH-3 Sea King (No 3D), SH-60 Seahawk, Shen- yang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Skjold- class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Somali Police Officer, Somali Soldier, Song-class Submarine, Sovremennyy-class Destroyer, Space Shuttle, Steregushchiy-class Frigate (No 3D), SU-25 Frogfoot


image


Spot Report Receiver (continued)


Stinger Missile Launcher

SU-27 Flanker, Su-37 Flanker, Sudanese Police Officer, Suda- nese Soldier, Super Dvora Mark II (No 3D), Suspect, Syrian Police Officer, Syrian Soldier, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Taliban, Tarantul-class Corvette (No 3D), Taurus ARV (No 3D), Technical Truck, Tiger- class Fast Attack Craft (No 3D), Tornado ADV (No 3D), Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), TRM 1000 Truck (No 3D), Tu-160 Blackjack (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 85 (YW 531H) APC (No 3D), Type 45 Destroyer, Type 10 MBT (No 3D), Type 22 Frigate (No 3D), Type 23 Frigate, Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), Udaloy-class Destroyer, Ugandan Police Officer, Ugandan Soldier, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), UK Soldier, Ula-class Submarine (No 3D), URO VAMTAC (No 3D), US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, National Security Cutter, Hamilton Class Cutter WHEC, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4,

US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US

Army M9, V-22 Osprey (No 3D), VAB APC, Vanguard-class Submarine (No 3D), VBCI APC (No 3D), VBL ATV, Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), VM 90 LSVW (No 3D), Walrus-class submarine (No 3D), Westland Lynx (No 3D), Wiesel AWC (No 3D), Marine Protector Class Patrol Boat, WS-61 Sea King (No 3D), WZ551 APC (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D), XM7 FIST-Bradley, Yuan-class Submarine (No 3D), ZIL-135 8x8 Truck, ZPU-4 AA Gun, ZSU-23-4 Shilka

HMMWV with Avenger


image


Section XIV - Appendixes

D-46 VT MAK


Subsurface Entity Default

Agosta 90B-class Submarine (No 3D), Akula-class Submarine (No 3D), AN/BLQ-11 UUV (No 3D), Astute-class Submarine (No 3D), Challenger-class Submarine (No 3D), Delta III-class Subma- rine (No 3D), Delta IV-class Submarine (No 3D), Dolphin-class Submarine (No 3D), Gotland-class Submarine (No 3D), Kilo-class Submarine (No 3D), Los Angeles-Class Submarine, Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Ohio-class Submarine, Oscar-class Submarine (No 3D), REMUS UUV, Romeo-class Submarine, Rubis-Class Submarine, Scorpene-class Submarine (No 3D), Siera II-class Submarine (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Ula-class Submarine (No 3D), Vanguard- class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Walrus-class submarine (No 3D), Yuan- class Submarine (No 3D)

Subsurface Agosta 90B-class Submarine (No 3D), Akula-class Submarine (No 3D), AN/BLQ-11 UUV (No 3D), Astute-class Submarine (No 3D), Challenger-class Submarine (No 3D), Delta III-class Subma- rine (No 3D), Delta IV-class Submarine (No 3D), Dolphin-class Submarine (No 3D), Gotland-class Submarine (No 3D), Kilo-class Submarine (No 3D), Los Angeles-Class Submarine, Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Ohio-class Submarine, Oscar-class Submarine (No 3D), REMUS UUV, Romeo-class Submarine, Rubis-Class Submarine, Scorpene-class Submarine (No 3D), Siera II-class Submarine (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Ula-class Submarine (No 3D), Vanguard- class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Walrus-class submarine (No 3D), Yuan- class Submarine (No 3D)

image


Surface Entity Default


D-48

Agosta 90B-class Submarine (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Albatros-class Fast Attack (No 3D), Alta-class Minehunter (No 3D), AN/BLQ-11 UUV (No 3D), Aquitaine-class Frigate (No 3D), Arleigh Burke- class Destroyer, Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), Auto Ferry, Bay-class DLS (No 3D), Bay- class Patrol Boat (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Cape-class Patrol Boat (No 3D), Challenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), Container Ship, Container Ship Loaded, Cruise Ship, Dabur-class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Delta III-class Submarine (No 3D), Delta IV- class Submarine (No 3D), Dolphin-class Submarine (No 3D), Durand de la Penne-class Destroyer (No 3D), Echo-class Survey Ship (No 3D), Eridan-class Minehunter (No 3D), F-22P Zulfiquar- class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Fishing Boat, Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), LCS Freedom Class (No 3D), Gaeta-class Minehunter, Gotland-class Subma- rine (No 3D), Guided Missile Destroyer, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Hauk-class Fast Attack (No 3D), Henry J Kaiser-class Oiler (No 3D), Holland Class OPV (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehu- nter (No 3D), LCS Independence Class (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), L-class Frigate (No 3D), Jet Ski, KAAN 19 Class Fast Patrol Craft, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR- 40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov-class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Nimitz-class Carrier, Niteroi- class Frigate (No 3D), Ohio-class Submarine, Oksoy-class Mine- hunter (No 3D), Oscar-class Submarine (No 3D), Passenger Ferry, Queen Elizabeth-class Carrier (No 3D), REMUS UUV, Rigid-Hulled Inflatable Boat, Rigid-Hulled Inflatable Boat - Civilian, River-class Patrol Vessel (No 3D), Romeo-class Subma- rine, Rubis-Class Submarine, Runnymede-class Landing Craft Utility 2000 (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sailboat, Sandown-class Minehu- nter (No 3D), Scorpene-class Submarine (No 3D), Sentinel-class (WPC) (No 3D), Siera II-class Submarine (No 3D), Sigma 9113- class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided

Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), SongS-celcatsiosnSuXbIVm-arAinpep,eSnodvixreems ennyy-class Destroyer, Super

Dvora Mark II (No 3D), Super Tanker, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Tugboat, TVyTpMe AK 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class)

Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type-80 Class Large Patrol Boat,


Surface Entity Default (continued)


Surface Disaggre- gated Movement

Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Ula-class Submarine (No 3D), National Security Cutter, Hamilton Class Cutter WHEC, Vanguard-class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), Walrus-class submarine (No 3D), Marine Protector Class Patrol Boat, Yuan-class Subma- rine (No 3D)


image


Large Ship Admiral Grigorovich-class Frigate (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Alta-class Minehunter (No 3D), Aquit- aine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Auto Ferry, Bay-class DLS (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Charles De Gaulle R91 (No 3D), Container Ship, Container Ship Loaded, Cruise Ship, De Zeven Provincien Class Frigate (No 3D), Delhi- class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), Eridan-class Minehunter (No 3D), F-22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Fishing Boat, Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Gaeta-class Minehunter, Gepard-class Frigate (No 3D), Guided Missile Destroyer, Krivak- class Guided Missile Frigate, Halifax-class Frigate (No 3D), Henry J Kaiser-class Oiler (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), LCS Independence Class (No 3D), Invincible-class Carrier (No 3D), Iroquois-class Destroyer (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov- class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Neustrashimyy-class Frigate (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Passenger Ferry, Queen Elizabeth-class Carrier (No 3D), Runnymede-class Landing Craft Utility 2000 (No 3D), Sachsen-class Frigate (No 3D), Sandown- class Minehunter (No 3D), Sentinel-class (WPC) (No 3D), Sigma 9113-class Frigate, Slava-class Guided Missile Cruiser (No 3D), Sovremennyy-class Destroyer, Super Tanker, Tugboat, Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type-80 Class Large Patrol Boat, Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, National Security Cutter, Hamilton Class Cutter WHEC, Victory- class Corvette (No 3D), Marine Protector Class Patrol Boat

Surface Multiple Hit Damage

Admiral Grigorovich-class Frigate (No 3D), Gepard-class Frigate (No 3D), Grisha-class Corvette (No 3D), Krivak-class Guided Missile Frigate, Jacinto-class Corvette (No 3D), Nanuchka III- class (No 3D), Neustrashimyy-class Frigate (No 3D), Pauk-class Corvette (No 3D), Steregushchiy-class Frigate (No 3D), Tarantul- class Corvette (No 3D)


image


Section XIV - Appendixes

D-50 VT MAK


Small Surface Ships

Tactical Radar Jammer

Tanker Refueling Boom

Fleet-class USV (No 3D), Skiff (Green), Skiff, Speedboat, Tiara 3900 Yacht

E-2 Hawkeye, EA-6B Prowler KC-135 Stratotanker

Torpedo Warhead Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo

TOW Missile Launcher

US Fighter Bomber Bomb Bay


US Heavy Bomber Bomb Bay

Vertical SAM Missile Launcher

HMMWV with TOW launcher, VM 90 LSVW (No 3D)


A-10 Thunderbolt, A-4 Skyhawk (No 3D), AMX (No 3D), AV-8B Harrier II, Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Mirage 2000, Mirage F1, Tornado ADV (No 3D), Xian JH-7 (No 3D)

B-2 Spirit, Harbin SH-5 ASW (No 3D), Il-76 Candid (No 3D), P-3 Orion, Xian H-6 Badger (No 3D)

Ahmad Yani-class Frigate, Alta-class Minehunter (No 3D), Aquit- aine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Charles De Gaulle R91 (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), F-22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal- class Minehunter (No 3D), LCS Freedom Class (No 3D), Gepard- class Frigate (No 3D), Grisha-class Corvette (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax- class Frigate (No 3D), Hauk-class Fast Attack (No 3D), Horizon- class Destroyer (No 3D), Iroquois-class Destroyer (No 3D), L- class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), KD- III-class Destroyer (No 3D), Khareff-class Corvette (No 3D), Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov-class (No 3D), La Fayette-class Frigate (No 3D), Milgem Class Corvette, Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Nanuchka III-class (No 3D), Neustrashimyy-class Frigate (No 3D), Niteroi-class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Pauk-class Corvette (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5- class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sovremennyy-class Destroyer, Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Victory-class Corvette (No 3D)


image


Visual Sensor 2S19 Msta-S (No 3D), Aardvark JSFU (No 3D), AAVC7A1 Landing Vehicle, Ababil UAV (No 3D), Achzarit APC (No 3D), Actros AHSVS (No 3D), Afghan Police Officer, Afghan Soldier, African Insurgent, Ahmad Yani-class Frigate, AMX-10RC (No 3D), AMX-30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT,

Aquitaine-class Frigate (No 3D), Aravis MRAP (No 3D), Arjun MBT (No 3D), AS-90 Artillery, Asagiri-class Destroyer (No 3D), ASCOD Ulan AIFV (No 3D), ASTROS II MLRS (No 3D), ATF

Dingo (No 3D), AUF1 155mm Howitzer (No 3D), Auto Ferry, Auverland A4 AVL (No 3D), Badger AEV (No 3D), Bandvagn 206 (No 3D), Beaver AVLB (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, Border Patrol Agent, Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Brazilian Soldier, Bremen-class Frigate (No 3D), BTR-60 APC, BTR-80 APC, BTR-90, Buffalo MRAP III,

Buffel ARV (No 3D), Bushmaster PMV (No 3D), C1 Ariete MBT (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Car Bomb, Centauro B1 (No 3D), CH-46E Sea Knight, Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, Container Ship, Container Ship Loaded, Cougar FSV, Coyote APC (No 3D), Cruise Ship, CUCV II (No 3D), CV9035 AFV, Dardo IFV (No 3D),

De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, DNG/DCL (No 3D), Durand de la Penne-class Destroyer (No 3D), EE-9 Cascavel (No 3D), Emer- gency Medical Technician, EMT Aladin (No 3D), EMT Luna (No 3D), ERC 90 Sagaie (No 3D), Eridan-class Minehunter (No 3D), ESK Mungo (No 3D), European Soldier, F-22P Zulfiquar-class Frigate (No 3D), Fenneck, Fishing Boat, Fleet-class USV (No 3D), Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Frankenthal- class Minehunter (No 3D), Freccia IFV (No 3D), LCS Freedom Class (No 3D), Fuchs APC (No 3D), FV 510 Warrior (No 3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D),

GAZ-69 Utility Vehicle, Ghillie Suit Soldier, GMC Yukon, Grizzly APC (No 3D), GTK Boxer APC (No 3D), HMMWV Utility Vehicle, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Husky ARV (No 3D), LCS Independence Class (No 3D), Insurgent, Invincible-class Carrier (No 3D), Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Iveco LMV (No 3D)

image


Section XIV - Appendixes

D-52 VT MAK


Visual Sensor Jackal MWMIK (No 3D), L-class Frigate (No 3D), Jet Ski, K1A1 MBT (No 3D), KAAN 19 Class Fast Patrol Craft, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), Khareff-class Corvette (No 3D), Kolkata-class Destroyer (No 3D), Kurdish Fighter, L-118 Howitzer (No 3D), La Fayette-class Frigate (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LAV III APC, LCAC, Legend Class (WMSL), Leopard 2 Tank, Libyan Police Officer, Libyan Soldier, LIV (SO) Serval (No 3D), Lupo-class Frigate (No 3D), M109 Howitzer, M1126 Stryker ICV, M113 APC, M1A2 Abrams MBT, M2A2 Bradley IFV, M35 Truck, M3A2 Bradley CFV, M577A2 Command Post, M58 MICLIC, M88 Medium Recovery Vehicle, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, M993 MLRS, M9 ACE, Maestrale-class Frigate (No 3D), Mamba APC (No 3D), Maveric UAS (No 3D), MBT 2000 (No 3D),

Merkava III MBT (No 3D), Merkava IV MBT (No 3D), Mideast Combatant, Mideast Combatant with RPG, MO-120RT-61 Mortar, Mohajer UAV (No 3D), Moudge-class Frigate (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MQ-8B Fire

Scout, MQ-9 Reaper UAV, MRAP-ATV, MRAP-CAT II Cougar, MRAP-CAT I MaxxPro, MT-LB APC, Murasame-class Destroyer (No 3D), Namer APC (No 3D), Navistar 7000 (No 3D), Niteroi- class Frigate (No 3D), Pakistani Police Officer, Pakistani Soldier, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzerhaubitze 2000 Howitzer, Passenger Ferry, Patria AMV (No 3D), EPP-III Patriot Power Generator, Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Police Officer, Pomornik (Zubr)-class LCAC (No 3D), MQ-1 Predator, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), RDE KZO (No 3D), Renault GBC 180 Truck (No 3D), RG-31

Nyala (No 3D), Rigid-Hulled Inflatable Boat, Rigid-Hulled Inflat- able Boat - Civilian, Roadside IED, RQ-11 Raven UAV, RQ-7 Shadow UAV (No 3D), Runnymede-class Landing Craft Utility 2000 (No 3D), Russian Rebels, Sachsen-class Frigate (No 3D), SAGEM Sperwer (No 3D), Sailboat, ScanEagle UAV (No 3D), Sergeant M16, Sigma 9113-class Frigate, Skiff (Green), Skiff, Somali Police Officer, Somali Soldier, Speedboat, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Super Dvora Mark II (No 3D), Super Tanker, Suspect, Syrian Police Officer, Syrian Soldier, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No

3D), T90A MBT (No 3D), Taliban, Taurus ARV (No 3D), Tech- nical Truck, Tiara 3900 Yacht, TRM 1000 Truck (No 3D), Tugboat, Type 85 (YW 531H) APC (No 3D), Type-80 Class Large Patrol Boat, Type 10 MBT (No 3D), Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D)

image


Visual Sensor (continued)

Ugandan Police Officer, Ugandan Soldier, UK Soldier, URO VAMTAC (No 3D), US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, National Security Cutter, Hamilton Class Cutter WHEC, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US

Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, VAB APC, VBCI APC (No 3D), VBL ATV, VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), VM 90 LSVW (No 3D), Wiesel AWC (No 3D), WZ551 APC (No 3D), XM7 FIST-Bradley, ZIL-135 8x8 Truck, ZPU-4 AA Gun, ZSU-23-4 Shilka


image


image

Table D-3: Systems and Configured Scripted Tasks, EntityLevel.sms


System Scripted Tasks

System Scripted Tasks

120mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 125mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 14.5mm Quad Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 25mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 30mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc Cargo Door Open_Cargo_Door, Close_Cargo_Door

Sliding Door Open_Sliding_Door, Close_Sliding_Door

Anti-Submarine Missile (Vertically Launched)

DDG Embedded Support Craft (LAMPS/RHIB)

Launch_ASW_Missile Embedded_Sector_SAR

Fast Roping Deploy_Ropes, FastRopeInsertion

Fighter Jet Fixed_Wing_Takeoff, Fixed_Wing_Land

Heavy Plane Fixed_Wing_Takeoff, Fixed_Wing_Land

High Maneuverability Fighter

Fixed_Wing_Takeoff, Fixed_Wing_Land

GAU-8 Avenger Strafe_Ground_Target, Attack_Aircraft_with_Guns Tracks move-to-location-path-plan, move-to-waypoint-path-plan Tracks/Amphibious move-to-location-path-plan, move-to-waypoint-path-plan Wheels (off road) move-to-location-path-plan, move-to-waypoint-path-plan Wheels (road) move-to-location-path-plan, move-to-waypoint-path-plan GSh-301 Cannon Strafe_Ground_Target, Attack_Aircraft_with_Guns

AK-47 Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc

image


Section XIV - Appendixes

D-54 VT MAK


image

Table D-3: Systems and Configured Scripted Tasks, EntityLevel.sms


System Scripted Tasks

System Scripted Tasks

Throw Grenades ThrowGrenade, ThrowGrenadeTarget

M16 rifle Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc

Handheld M240B Machine Gun

Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc

M249 SAW Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc

Handheld M60 Machine Gun

Homing Torpedo Capa- bility (Forward Launched)

Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc


Delayed_homing, Delayed_homing_ASW, Launch_Torpe- do_Salvo

Flee From Explosions bhave-Flee_From_Explosion

Lifeform Suppression Suppressed_Crouch, Suppressed_Prone

M2HB Machine Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc

M203 Grenade Launcher

Fire_M203_at_Location, Fire_M203_at_Target

M230 Chain Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc M240 Machine Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc M60 Machine Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc M61 Vulcan Strafe_Ground_Target, Attack_Aircraft_with_Guns

Naval Depth Charge Deployment

Naval Mine Deploy- ment

Drop_Naval_Depth_Charge, Drop_Na- val_Depth_Charge_At_Location

Drop_Naval_Mine, Drop_Naval_Mines_Along_Route

Naval Mine Sweep Naval_Mine_Sweep

Pedestrian Crowd Movement


Pedestrian Traffic Generator

Crowd_Around, Crowd_Around_Location, Crowd_In_- Front_Of, Crowd_Along_Line, Disperse_Crowd, Wander_In_Area, Protest, Protest_Along_Line

Create_Initial_Pedestrians, Create_Pedestrians, Delete_Cre- ated_Pedestrians

Periscope Raise_Periscope, Lower_Periscope

Dipping SONAR Sensor

Sonar_Dip

image

Sonobuoy Deployer Deploy_Sonobuoy, Deploy_Sonobuoys_Along_Route Tanker Refueling Boom Deploy_Refueling_Boom, Stow_Refueling_Boom


Mortar, 120mm weapon aggregate,

assemblies

A single 120mm mortar tube. Capable of indirect fire missions.

Active RADAR Sensor


Aerial Refueling Resupply

sensor all Allows an entity to detect other objects through RADAR. Also publishes emitter beams that represent the emissions from the sensor.

other all Gives the unit the capability to resupply aviation fuel to airborne units from an airborne unit.

122mm Howitzer weapon aggregate,

assemblies

Artillery piece capable of indirect fire missions.

152mm Howitzer Auto

weapon aggregate, assemblies

Artillery piece capable of indirect fire missions. Uses auto-loader.

155mm Howitzer weapon aggregate,

assemblies

Artillery piece capable of indirect fire missions.

Bomb, 2000lb JDAM

weapon aggregate, assemblies

A precision guided bomb. Uses GPS

Mk 45 5-inch Gun weapon aggregate,

assemblies

A naval gun capable of indirect fire operations.

9K330 Surface- to-Air Missile Launcher

weapon aggregate, assemblies

An anti-air missile. Uses radar guidance.

9P140 MRL weapon aggregate,

assemblies

Multiple Rocket Launcher System Russia

AIM-120

AMRAAM Missile

weapon aggregate, assemblies

A medium range anti-air missile. Uses radar guidance.

Communications Jammer

electron- icwarfare

all Jamming system for radios, cell phones, satellite phones, UAVs, etc.

Harpoon Antiship Missile

weapon aggregate, assemblies

A long range anti-ship missile. Radar guided.

M993 MLRS weapon aggregate,

assemblies

Torpedo, Mark 54 weapon aggregate,

assemblies

Multiple Rocket Launcher System USA

An anti-ship and anti-submarine torpedo. Can be air-dropped.

Radar Jammer electron- icwarfare

all Jamming system for acquisition and tracking/guidance radars.

Guided Bomb weapon aggregate,

assemblies

A precision guided bomb. Uses optical or other non-radar guid- ance.


image


Section XIV - Appendixes

D-56 VT MAK


RIM-66 SAM weapon aggregate,

assemblies

A surface to air missile. Uses radar guidance.

Sidewinder Anti- Air Missile

Stinger Anti-Air Missile

Tomahawk Cruise Missile

weapon aggregate, assemblies

weapon aggregate, assemblies

weapon aggregate, assemblies

A short range anti-air missile. Uses IR guidance.

An anti-air missile with limited altitude. Uses IR guidance.

A long range guided land attack missile. Uses primarily GPS and optical guidance.

Unguided Bomb weapon aggregate,

assemblies

A bomb intended to have effects in an area.

Torpedo, Type 40 (RPK-6 Vodopad SUBROC)

weapon aggregate, assemblies

An anti-ship and anti-submarine torpedo with SUBROC configura- tion. Can be deck-launched.

Air Defense RADAR Sensor

sensor all Allows an entity to detect aircraft through RADAR. Also publishes emitter beams that represent the emissions from the sensor.

Air-Drop Supply other all Gives the unit the capability to

resupply ground units from the air.

Active RADAR Sensor


Aircraft Aggre- gated Movement

sensor all Allows an entity to detect other objects through RADAR. Also publishes emitter beams that represent the emissions from the sensor.

aggregated aggregate Aircraft aggregated movement.

Biological Weapon weapon aggregate,

assemblies

A weapon system that create biological contamination areas.

Booby Trap Setter engineering-

object- creation

Bridge Builder engineering- object- creation

aggregate, assemblies


aggregate, assemblies

A system which provides the capability to create booby traps.


A system which provides the capability to create bridges.

Chemical Weapon weapon aggregate,

assemblies

A weapon system that create chemical contamination areas.

Ditch Digger engineering- object- creation

aggregate, assemblies

A system which provides the capability to create a ditch.


image


SIGINT Sensor sensor all Allows an entity to detect other

entities by their radio and RADAR emissions.

Engagement Report Generator


Engineering Object Sensor

other all Allows the entity to send engage- ment reports through its radio when it is attacking an enemy.

sensor all Allows an entity to detect engi- neering objects.

Engineering Obstacle Destroyer


Explosive Hazard and Simple Obstacle Destroyer

obstacle- destruction


obstacle- destruction

aggregate, assemblies


aggregate, assemblies

A system which provides the capability to destroy/breach engi- neering obstacles. Meant to be used by units with specialized equipment.

A system which provides the capability to destroy explosive hazards as well as destroy/breach simple obstacles.

FASCAM weapon aggregate, assemblies

Artillery used to deploy mine- fields.

Fortification Builder

engineering- object- creation

aggregate, assemblies

A system which provides the capability to construct fortifica- tions.

Ground Aggre- gated Movement


Ground Combat Behaviors

aggregated aggregate Basic movement capabilities for

any ground-based aggregated unit, both vehicle and DI.

other all Enables behaviors appropriate for ground combat units.

IFF Transponder other all Sends IFF data, when turned on.

IFF is off by default.

Infantry Aggre- gated Movement

aggregated aggregate Infantry aggregated movement.

IR Sensor sensor all Allows an entity to detect other

objects through Infrared.

Limit Entity Exis- tence


Mechanized Aggregated Movement

other all Used to control the life span of the object this system is attached to. Once it's life span is up the object is removed from the simu- lation.

aggregated aggregate Mechanized aggregated move-

ment.


image


Section XIV - Appendixes

D-58 VT MAK


Mine Dispenser engineering-

object- creation

aggregate, assemblies

A system which provides the capability to create minefields.

MOPP Gear other aggregate, assemblies

Equips the unit with MOPP gear which allows MOPP level transi- tions.

Motorized Aggre- gated Movement

aggregated aggregate Motorized aggregated movement.

NBC Sensor sensor all Allows an entity to detect areas

contaminated with nuclear, biological, or chemical agents.

Nuclear Weapon weapon aggregate,

assemblies

A weapon system that create nuclear contamination areas.

Obstacle Builder engineering-

object- creation

aggregate, assemblies

A system which provides the capability to construct basic obstacles.

Passive RADAR Sensor

sensor all Allows an entity to detect other objects through RADAR. No emitters are published for this sensor.

Ground Resupply other all Gives the unit the capability to

resupply units on the ground.

Riverine Aggre- gated Movement


Ship Aggregated Movement

aggregated aggregate Riverine movement system for

aggregate of one light patrol craft.

aggregated aggregate Ship movement system for aggre-

gate of one type ships.

Simple Obstacle Destroyer

obstacle- destruction

aggregate, assemblies

A system which provides the capability to destroy/breach simple obstacles. Meant to be used by units without specialized equipment.

SONAR Sensor sensor all Allows an entity to detect other

objects through SONAR.

Spot Report Generator

other all Allows the entity to send spot reports through its radio when its sensors detect other entities in the scenario.


image


Spot Report Receiver


Subsurface Aggregated Movement

Tank Aggregated Movement

other all Allows an entity to receive spot reports from other entities over the radio, and add these contacts to its list of known entities. By default, spot reports expire after 5 minutes.

aggregated aggregate Subsurface movement system for

AggregateSMS submarines. aggregated aggregate Tank aggregated movement.

Visual Sensor sensor all Allows an entity to detect other

objects through visible light.

image


image

Table D-5: System usage, AgregateLevel.sms


System Entities that Use System

System Entities that Use System

Mortar, 120mm AR CAV TRP US, MECH BN US solo, Mortar PLT US, Mortar SP PLT US, TANK BN RU solo, TANK BN US solo

Active RADAR Sensor


Aerial Refueling Resupply

ADA BN RU solo, EA-18G Growler, F-16C (Air Superiority - improved), F-16C (Air Superiority), F/A-18 (Ground Attack), F/A- 18 (Ship Attack), Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, Sub, RU SSP, Lada

122mm Howitzer Artillery BTY RU, FA BN RU solo

152mm Howitzer Auto

Artillery SP BTY - NBC, Artillery SP BTY RU

155mm Howitzer Artillery SP BTY US, FA BN US solo, Artillery BTY US

Bomb, 2000lb JDAM

F/A-18 (Ground Attack)

Mk 45 5-inch Gun Ship, US DDG, Arleigh Burke

9K330 Surface- to-Air Missile Launcher

ADA BN RU solo, SAM BTY RU

9P140 MRL MRL BTY RU

AIM-120

AMRAAM Missile

Communications Jammer

F-16C (Air Superiority - improved), F-16C (Air Superiority), F/A- 18 (Ground Attack)

MI BN US solo, MI CO US, MI PLT US


image


Section XIV - Appendixes

D-60 VT MAK


Harpoon Antiship Missile

F/A-18 (Ship Attack), Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry

M993 MLRS MLRS BTY US

Torpedo, Mark 54 Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry Radar Jammer EA-18G Growler

Guided Bomb

RIM-66 SAM Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry

Sidewinder Anti- Air Missile

Stinger Anti-Air Missile

Tomahawk Cruise Missile

Unguided Bomb

Torpedo, Type 40 (RPK-6 Vodopad SUBROC)

Air Defense RADAR Sensor

Air-Drop Supply

Active RADAR Sensor

Aircraft Aggre- gated Movement

EA-18G Growler, F-16C (Air Superiority - improved), F-16C (Air Superiority), F/A-18 (Ground Attack), F/A-18 (Ship Attack)

ADA BN US solo, ADA BTY US, ADA PLT US


Ship, US DDG, Arleigh Burke


Sub, RU SSP, Lada


SAM BTY RU


F-16C (Air Superiority), F/A-18 (Ground Attack), F/A-18 (Ship Attack)

AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AVN SPT TROOP, Civilian

Aircraft, EA-18G Growler, F-16C (Air Superiority - improved), F- 16C (Air Superiority), F/A-18 (Ground Attack), F/A-18 (Ship Attack), AIR ATK SQDN US solo, _Air FW template, _Air RW template

Biological Weapon Artillery SP BTY - NBC

Booby Trap Setter ENG BN US solo, Eng Mob Aug CO, ENG PLT US Bridge Builder ENG BN US solo, Eng Mob Aug CO, ENG PLT US Chemical Weapon Artillery SP BTY - NBC, Artillery SP BTY RU

Ditch Digger ENG BN US solo, Eng Mob Aug CO, ENG PLT US, Mech Inf CO US

SIGINT Sensor MI BN US solo, MI CO US, MI PLT US

image


Engagement Report Generator


Engineering Object Sensor


Engineering Obstacle Destroyer

ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,

AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP

BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian Aircraft, Civilian CO, CSS CO, CSS PLT, EA-18G Growler, ENG BN US

solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A-18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US

solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR ATK SQDN US solo, SAM BTY RU, Scout Hvy CO US,

Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,

Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,

_SPA template, _Tank unit template, _Towed arty template,

_Unarmored foot template, _Unarmored wheeled template

ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,

AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CIV BN solo, Civilian CO, CSS BN US solo, CSS CO, CSS PLT, ENG BN US solo, Eng

Clearance CO, Eng Mob Aug CO, ENG PLT US, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US,

Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, Weapons

CO US, _Ground master template, _Light armor template,

_Mechanized template, _SPA template, _Tank unit template,

_Towed arty template, _Unarmored foot template, _Unarmored wheeled template

ENG BN US solo, Eng Mob Aug CO, ENG PLT US


image


Section XIV - Appendixes

D-62 VT MAK


Explosive Hazard and Simple Obstacle Destroyer

Eng Clearance CO

FASCAM Artillery BTY RU, Artillery SP BTY US, Artillery BTY US

Fortification Builder

Ground Aggre- gated Movement

Ground Combat Behaviors

ENG BN US solo, Eng Mob Aug CO, ENG PLT US

IFF Transponder AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AVN SPT TROOP, EA-18G

Growler, F-16C (Air Superiority), F/A-18 (Ground Attack), F/A- 18 (Ship Attack), AIR ATK SQDN US solo, _Air FW template

Infantry Aggre- gated Movement

CIV BN solo, Civilian CO, INF BN RU solo, INF BN US solo, Mortar PLT US, Rifle CO RU, Rifle CO US, _Unarmored foot template

IR Sensor ADA BN US solo, ADA BTY US, ADA PLT US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, AVN SPT TROOP, AIR ATK SQDN US solo, TANK BN US solo, Tank CO US, TANK PLT US, TANK SEC US

Limit Entity Exis- tence

Mechanized Aggregated Movement


ADA BN RU solo, Artillery SP BTY - NBC, Artillery SP BTY RU, Artillery SP BTY US, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, IFV SEC US, MECH BN RU solo,

MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, Mortar SP PLT US, SAM BTY RU, Scout Hvy CO US,

Scout Hvy PLT US, _Light armor template, _Mechanized template, _SPA template

Mine Dispenser ENG BN US solo, Eng Mob Aug CO, ENG PLT US

image


MOPP Gear ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,

AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CSS BN US solo, CSS CO, CSS PLT, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU

solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN

US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU,

Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US, TANK BN RU

solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, Weapons CO US, _Ground master template,

_Light armor template, _Mechanized template, _SPA template,

_Tank unit template, _Towed arty template, _Unarmored foot template, _Unarmored wheeled template

Motorized Aggre- gated Movement

ADA BN US solo, ADA BTY US, ADA PLT US, Artillery BTY RU, CSS BN US solo, CSS CO, CSS PLT, FA BN RU solo, FA BN US

solo, Artillery BTY US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, MRL BTY RU, Scout

Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US,

Weapons CO US, _Towed arty template, _Unarmored wheeled template

NBC Sensor ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,

AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CIV BN solo, Civilian CO, CSS BN US solo, CSS CO, CSS PLT, ENG BN US solo, Eng

Clearance CO, Eng Mob Aug CO, ENG PLT US, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US,

Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, Weapons CO US,

_Ground master template, _Light armor template, _Mechanized template, _SPA template, _Tank unit template, _Towed arty template, _Unarmored foot template, _Unarmored wheeled template

Nuclear Weapon Artillery SP BTY - NBC

Obstacle Builder ENG BN US solo, Eng Mob Aug CO, ENG PLT US

image


Section XIV - Appendixes

D-64 VT MAK


Passive RADAR Sensor

Ground Resupply CSS BN US solo, CSS CO, CSS PLT Riverine Aggre-

gated Movement

Ship Aggregated Movement

Simple Obstacle Destroyer

Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry


ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,

AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CIV BN solo, Civilian CO, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN

US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL

BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motor- ized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,

Weapons CO US, _Ground master template, _Light armor template, _Mechanized template, _SPA template, _Tank unit template, _Towed arty template, _Unarmored foot template,

_Unarmored wheeled template

SONAR Sensor Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, Sub, RU SSP, Lada

image


Spot Report Generator


Spot Report Receiver

ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,

AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP

BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian Aircraft, Civilian CO, CSS CO, CSS PLT, EA-18G Growler, ENG BN US

solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A-18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US

solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR ATK SQDN US solo, SAM BTY RU, Scout Hvy CO US,

Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,

Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,

_SPA template, _Tank unit template, _Towed arty template,

_Unarmored foot template, _Unarmored wheeled template

ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,

AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP

BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian Aircraft, Civilian CO, EA-18G Growler, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A-18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US solo, MECH

BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI

BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR ATK

SQDN US solo, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,

Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,

_SPA template, _Tank unit template, _Towed arty template,

_Unarmored foot template, _Unarmored wheeled template


image


Section XIV - Appendixes

D-66 VT MAK


Subsurface Aggregated Movement

Tank Aggregated Movement

Sub, RU SSP, Lada


AR CAV TRP US, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, _Tank unit

template

Visual Sensor ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US, AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP

BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian CO, CSS BN

US solo, CSS CO, CSS PLT, EA-18G Growler, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A- 18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR

ATK SQDN US solo, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,

Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,

_SPA template, _Tank unit template, _Towed arty template,

_Unarmored foot template, _Unarmored wheeled template

image


image

Table D-6: Systems and Configured Scripted Tasks, AggregateLevel.sms


System Scripted Tasks

System Scripted Tasks

Mortar, 120mm Indirect_Fire, Limited_Munition_Attack

Aerial Refueling Resupply

Provide_Supplies, Change_Supplying_Command

122mm Howitzer Indirect_Fire, Limited_Munition_Attack

152mm Howitzer Auto

Indirect_Fire, Limited_Munition_Attack

155mm Howitzer Indirect_Fire, Limited_Munition_Attack

Bomb, 2000lb JDAM

Bomb_Location, Limited_Munition_Attack, Ground_Attack

Mk 45 5-inch Gun Indirect_Fire, Limited_Munition_Attack

image


image

Table D-6: Systems and Configured Scripted Tasks, AggregateLevel.sms


System Scripted Tasks

System Scripted Tasks

9K330 Surface-to- Air Missile Launcher

Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats

9P140 MRL Indirect_Fire, Limited_Munition_Attack

AIM-120

AMRAAM Missile

Communications Jammer

Harpoon Antiship Missile

Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats

EW_Attack, Activate_Jammer, Deactivate_Jammer


Limited_Munition_Attack, Attack_with_Antiship_Missile, React_To_Naval_Threats_Missile

M993 MLRS Indirect_Fire, Limited_Munition_Attack

Torpedo, Mark 54 Limited_Munition_Attack, Attack_with_Torpedo, React_To_Na- val_Threats_Torpedo

Radar Jammer EW_Attack, Activate_Jammer, Deactivate_Jammer Guided Bomb Bomb_Location, Limited_Munition_Attack, Ground_Attack

RIM-66 SAM Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats

Sidewinder Anti-Air Missile

Stinger Anti-Air Missile

Tomahawk Cruise Missile

Limited_Munition_Attack, Attack_with_AntiAir_Missile, React_To_Air_Threats

Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats

Limited_Munition_Attack, Attack_with_Land-Attack_Missile

Unguided Bomb Bomb_Location, Limited_Munition_Attack, Ground_Attack

Torpedo, Type 40 (RPK-6 Vodopad SUBROC)

Limited_Munition_Attack, Attack_with_Torpedo, React_To_Na- val_Threats_Torpedo

Air-Drop Supply Provide_Supplies, Change_Supplying_Command

Aircraft Aggre- gated Movement

Maximum_Speed_Modifier

Biological Weapon Biological_Attack, NBC_Attack

Booby Trap Setter Create_Booby_Trap, Improve_Booby_Trap Bridge Builder Construct_Bridge, Improve_Bridge Chemical Weapon Chemical_Attack, NBC_Attack

Ditch Digger Create_Anti-Tank_Ditch, Improve_Ditch, Create_Dry_Gap

Engineering Obstacle Destroyer

Destroy_Obstacle, Destroy_Fortification, Destroy_Ditch, Destroy_Bridge, Destroy_Explosive, Breach_Obstacles, Improve_Breach


image



Section XIV - Appendixes

D-68 VT MAK


image

Table D-6: Systems and Configured Scripted Tasks, AggregateLevel.sms


System Scripted Tasks

System Scripted Tasks

Explosive Hazard and Simple Obstacle Destroyer

Destroy_Explosive_Hazard, Destroy_Obstacle, Breach_Obsta- cles, Improve_Breach

FASCAM FASCAM

Fortification Builder Construct_Barricade, Improve_Fortification, Construct_Forti- fied_Line, Construct_Fortified_Area, Construct_Strong_Point

Ground Aggre- gated Movement

Ground Combat Behaviors

Infantry Aggre- gated Movement

Mechanized Aggre- gated Movement

Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path

Attack_Target


Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path

Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path

Mine Dispenser Create_Minefield MOPP Gear Change_MOPP_Level

Motorized Aggre- gated Movement

Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path

Nuclear Weapon Nuclear_Attack, NBC_Attack

Obstacle Builder Construct_Abatis, Improve_Obstacle, Construct_Barbed_Wire, Construct_Berm

Ground Resupply Provide_Supplies, Change_Supplying_Command

Riverine Aggre- gated Movement

Ship Aggregated Movement

Simple Obstacle Destroyer

Subsurface Aggre- gated Movement

Tank Aggregated Movement

Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path

Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path

Destroy_Obstacle, Breach_Obstacles, Improve_Breach


Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path

Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path


image



Section XIV - Appendixes

    1. VT MAK


      image MÄK Products Glossary

      This glossary defines terms used in MAK product documentation.


      absolute dead reckoning

      A method of dead-reckoning in which an application uses the time stamps contained within state updates if the sender is using absolute time stamping. Contrast with rela- tive dead reckoning.

      aggregate

      The combination of individual entities, aggregates, or both into a single object. For example, an organizational group such as a platoon.

      API

      Application Programming Interface.


      articulated part

      A part of an entity that is capable of movement relative to the entity, such as a turret or gun.

      attached part

      An object that is attached to another object, such as a rocket attached to a jet.

      body coordinate frame

      A coordinate framework centered on an entity. To represent the orientation of an entity, an application uses Euler angles or a rotation matrix that rotates from a reference frame to the body coordinate frame.

      channel

      A channel renders the view of an observer in a 3D visualization application.


      clipping


      A feature that prevents the display of terrain and objects or parts of objects, that are closer than or farther than specific distances from the observer.


      clipping planes

      The range of distances from the observer (near clipping and far clipping) in which an application clips objects.

      culling


      The process of discarding database objects which are not within view, and therefore need not be rendered and displayed.

      Cartesian coordinates

      A system for indicating location by means of three planes intersecting at right angles to one another at the origin.

      Data Distribution Management

      The set of HLA services used to specify the routing of data between publishers and subscribers. DDM adds greater control over the Declaration Management (DM) services that only specify filtering based on the class of the data (e.g., ground vehicle versus aircraft). DDM uses the data content to express regions of interest and regions of affect whose overlap establish a communication channel. An example is geographic filtering where a publisher indicates a region around the entity or effect and a subscriber indicates a region expressing its sensor range.

      dead-reckoning

      A process by which an application calculates the expected location of an entity during periods between state updates, based on velocity, acceleration, and rotational velocity.


      DDM

      Data Distribution Management.


      Defense Modeling and Simulation Office

      The former name of the executive secretariat for the Executive Council on Modeling and Simulation (EXCIMS), which provided a full-time focal point for information concerning Department of Defense modeling and simulation (M&S) activities.

      Renamed Modeling and Simulation Coordination Office. Currently the MSCO promulgates M&S policy, initiatives, and guidance to promote cooperation among DoD components to maximize efficiency and effectiveness.


      DIS

      Distributed Interactive Simulation.


      DIS data packets

      See Protocol Data Unit.

      display engine

      An object in an application that can render 3D data.

      Distributed Interactive Simulation

      The DIS protocol is a set of standards that govern how participating applications share information about the virtual world. The protocol specifies a set of packets, called protocol data units (PDUs), that communicate this information. Each PDU identifies the sender and contains other information depending on the PDU type. The DIS protocol also specifies when and how frequently PDUs are sent.

      The DIS protocol has been superseded by the High-Level Architecture for use by the Department of Defense.

      DMSO

      See Defense Modeling and Simulation Office.


      element definition

      In VR-Forces and VR-Vantage, an element definition specifies all of the visualizers that control the various aspects of visualizing a scene element. For example, an element defi- nition includes the main model or military symbology, trailing effects, cockpit displays, and so on.

      emitter


      entity


      A simulated device on an entity that emits electromagnetic radiation, for example, radar.


      An element in a simulation, such as a vehicle or a person, that is represented in the simulation through the issuance of state messages.


      entity maintenance

      A process by which the MAK Data Logger compensates for discontinuities following a time jump. The Logger sends out interim state messages for entities that were present before the time jump so that they do not time out before the next update message arrives.


      entity-type

      A list of seven components as specified by the DIS protocol and the HLA RPR FOM. If none of the seven components contains a wildcard (-1) value, then the entity type refers to a specific, narrowly-defined entity. If some components contain a wildcard, then the entity type refers to a class of entities. A larger number of wildcards indicates a broader, more general class.

      The components of an entity-type are:

      • Entity kind

      • Domain

      • Country

      • Category

      • Subcategory

      • Specific

      • Extra.

environmental process

According to the IEEE 1278.1a specification (DIS), environmental process PDUs communicate simple environment variables, small scale environmental updates, and embedded processes.

Euler angles

A set of three angles used to describe the orientation of an entity as a set of three succes- sive rotations about three different orthogonal axes (x, y, and z). These angles specify successive rotations needed to transform from a reference coordinate system to the entity’s body coordinate system.


event


exercise


An interaction between objects or between an object and the terrain, such as firing of a munition, or a collision of entities.


The DIS term for a one or more interacting simulation applications. Compare to feder- ation execution in HLA.

exercise connection

The object (DtExerciseConn) through which a VR-Link application connects to the network. State messages are sent through the exercise connection and information about remote entities is received through the exercise connection. (All MAK products are VR-Link applications.)

exercise ID

A numeric identification for a DIS simulation exercise.


FED file

Federation Execution Data file. The Federation Execution Data is the subset of FOM data needed and read by the RTI. VR-Link applications also read the FED file.


federate


A connection to the RTI. Typically a single simulation application can be thought of as a federate.

federation

A group of HLA federates capable of playing in the same federation execution.

Federation Object Model

Defines the data content of a federation execution.

federation execution

The federation execution represents the actual operation, over time, of a subset of the federates and the RTI initialization data taken from a particular federation. A federa- tion execution is the logical equivalent of a DIS simulation exercise.

field of view

Controls the perspective of the observer.

A wide field of view creates an effect like that of a wide-angle camera lens. Objects appear smaller and farther away from the observer, since the observer coverage spans a wider area. Depth become exaggerated.

A narrow field of view creates an effect like that of a telephoto lens. Objects appear larger and closer to the observer, and the overall scene depth appears flattened. The distances between objects appears compressed.

filter range

A setting that prevents distant entities from being processed while allowing distant terrain to appear normally.

FOM

See Federation Object Model.


FOM Module

In HLA Evolved, defines additional modular data content for a federation execution, usually extensions to an existing FOM. (Also supported by the HLA 1.3 and HLA 1516 versions of the MAK RTI. Per the HLA Evolved interface specification:

“A partial FOM (containing some or all OMT tables) that specifies a modular compo- nent of a FOM. A FOM module may contain classes not inherent to it but upon which the FOM module depends, i.e., superclasses to the modular components. These super- classes will be included in the FOM module either as complete or scaffolding defini- tions.”

frame rate

The rate at which the application displays updated images.

ground clamping

A process by which the a 3D visualization application keeps an entity anchored to the surface of its terrain database, regardless of the altitude data contained in its entity state message.

geocentric coordinates

A coordinate system calculated with respect to the earth’s center. The origin of the geocentric coordinate system is the center of the earth. The positive X-axis passes through the prime meridian at the equator; the positive Y-axis passes through 90 degrees east longitude at the equator; and the positive Z-axis passes though the north pole.

geodetic coordinates

A coordinate system in which position is determined relative to a reference ellipsoid, such as the surface of the earth at sea level. In MAK applications, geodetic coordinates consist of latitude and longitude in radians, and altitude in meters above the reference ellipsoid.

gridded data

Data that has been processed in a rectangular array of points, in X, Y or latitude/longi- tude, at which single data values define a two dimensional function. According to the IEEE 1278.1a specification, gridded data transmits information about large-scale or high-fidelity spatially and temporally varying ambient fields and about environmental processes and features.


guise


An alternative entity type used to display an object depending on the force ID. For example, a tank could look like an M1A1 to friendly forces and a T72 to hostile forces.


head-up display

A set of indicators and readouts superimposed onto a graphics display. Also called an overlay.

heartbeat

In DIS, the frequency with which current PDUs are sent to the network regardless of whether or not the entity’s state has changed.

High-Level Architecture

The High Level Architecture (HLA) for simulations is a U. S. Department of Defense (DOD)-wide initiative to provide an architecture to support interoperability and reuse of simulations. The HLA supersedes DIS for the DOD.


HLA

See High-Level Architecture.


interaction

A message describing a simulation event. An interaction describes an event, it does not update an object’s state.

Logger control PDUs

A set of DIS PDUs or HLA interactions that let you control the MAK Logger remotely.

logical range

A suite of TENA Resources, sharing a common object model, that work together for a given range event. Similar in concept to the HLA Federation.

Local RTI Component

The libraries on a computer that implement an RTI. A federate communicates with the HLA network through the LRC.

LRC

See Local RTI Component.


MÄK Technologies Lisp

An adaptation of the Lisp language used in configuration files for MAK products.


message


A general term used to refer to DIS PDUs and HLA interactions and state updates. In TENA, a message is similar to an HLA interaction.


MIM


The MOM & Initialization Module (MIM) allows for extensions to be made to the HLA standard MOM. It is a subset of the FOM that contains OMT tables that describe the HLA MOM. The MIM also contains additional predefined HLA constructs such as object and interaction roots, data types, transportation types and dimensions. HLA specifies a standard MIM that is incorporated into all FDDs auto- matically by the RTI. The standard MIM can be replaced with a user-supplied MIM containing the standard MIM plus extensions.

model definition

In VR-Forces and VR-Vantage, a model definition specifies the 3D model and other basic attributes of a model. It is referenced by an element definition.

Modeling and Simulation Coordination Office

The executive secretariat for the Executive Council on Modeling and Simulation (EXCIMS), which provided a full-time focal point for information concerning Depart- ment of Defense modeling and simulation (M&S) activities. The MSCO promulgates M&S policy, initiatives, and guidance to promote cooperation among DoD compo- nents to maximize efficiency and effectiveness. (Formerly DMSO)


MSCO


MTL


Modeling and Simulation Coordination Office. (Formerly DMSO.)


See MÄK Technologies Lisp.


orientation clamping

Adjusts the pitch and roll of an entity so that it appears properly seated when the terrain is inclined. For example, if a tank is moving horizontally across the face of a hill, orien- tation clamping prevents the tank from appearing level, and therefore, partially embedded into the hillside. Used with ground clamping.


object


An element in a simulation that has persistence, as opposed to an interaction, which is a transient element.

object handle

An integer that an application uses to identify a particular object in RTI service calls. An object handle is meaningful only to a particular federate. The same object can be known to different federates by different object handles.


object name

A character string that can be used to identify an object. In HLA, the object name is known to the RTI, and the RTI provides functions to find out an object’s name, given its handle, and vice versa. Object names can be chosen by applications that register the objects with the RTI, however if you do not want to choose names for objects, the RTI will assign names for you.

observer

In MAK 3D applications, the point of view into the scene. (Called the eyepoint in MAK Stealth 6.x and earlier.)

PDU

See Protocol Data Unit.


Protocol Data Unit

A unit of data message (packet) that is passed on a network between DIS simulation applications.

radio transmitter

A simulated device on an entity, capable of transmitting radio communications.

radio receiver

A simulated device on an entity, capable of receiving radio communications.

Realtime Platform Reference FOM

An HLA reference FOM based on the DIS protocol.

recording

A Data Logger file that stores a history of the interactions in a simulation for playback.

reflected entity list

A list of entities simulated by remote applications (federates in HLA) and about which the local simulation has received information over the network.

reference FOM

A FOM designed to be used as a whole, or with modification, by a wide variety of similar federation executions.

relative dead reckoning

A method of dead reckoning in which an application approximates the location of an object based on the local time of receipt of the last state update message.


remote display engine

A display engine running in an application that is separate from the master application, and which is controlled by the master application.

RID file

See RTI Initialization Data.

RTI Initialization Data

The initialization data required by the RTI for operation.

Data required by an RTI during initialization, independent of the FOM being used. RID data is usually dependent on a specific implementation of the RTI.

RPR FOM

See Realtime Platform Reference FOM.


RTI

See Run-Time Infrastructure.


Run-Time Infrastructure

A library and other supporting software that implements the HLA interface specifica- tion. All federates communicate with one another in an HLA environment through RTI functions.

scene element

In VR-Vantage and VR-Forces, any object that is rendered in the scene, such as an entity model, interaction, or tactical graphic.

Simulation Interoperability Standards Organization

A group that seeks to promote modeling and simulation interoperability and reuse for the benefit of diverse M&S communities, including developers, procurers, and users, world-wide.

simulation time

In VR-Forces, simulation time is used in dead-reckoning of remote entities and thresh- olding of local entities. Typically, simulation time is set once during each iteration of the application's main simulation loop so that all entities are dead-reckoned based on the same value of current time.


SISO

See Simulation Interoperability Standards Organization.


smooth period

The period of time over which trajectory smoothing takes place.


smoothing

A method of ensuring that transitions from an entity’s dead-reckoned position to its actual position are not so abrupt as to be visually disconcerting.


state


tape


The current status of an object, including location, direction of movement, extent of damage, and so on.


An alternative term for a Logger recording. Not a physical magnetic tape.


terrain following

In a 3D visualization application, causes the observer (eyepoint) to maintain a constant distance above the terrain surface. The observer’s height changes in tandem with the peaks and valleys as it passes over the geography.

timeout


The period of time in which an application continues to display an entity after that entity’s update messages have stopped appearing on the network. Time-outs are usually not used in HLA because there is no set frequency (no heartbeat) for transmitting messages.

timescale

A factor by which time is accelerated or slowed during playback of a Data Logger recording.

topographic coordinates

A right-handed Cartesian coordinate system whose X-Y plane is tangent to the earth's surface at the origin, with the positive X axis pointing north, the positive Y axis pointing east, and the positive Z axis pointing down. There are an infinite number of topographic coordinate systems – one for each point on the earth's surface.

topographic coordinate frame

A coordinate frame in the context of the terrain.

trajectory smoothing

A method used by to smooth positional discontinuities that could occur when new state updates arrive.

UDP port

A network channel through which an application sends and receives data for DIS exer- cises.


Universal Transverse Mercator

In general, a non-cartesian coordinate system in which the X, Y, and Z correspond to easting (nearly east), northing (nearly north), and height above an ellipsoid that approx- imates the surface of the earth.

UTM

See Universal Transverse Mercator.


view control messages

A set of programmatic messages that let you control the view in VR-Vantage applica- tions remotely.


image

Index


--enableVSync command-line option 6-19

--noAppDataEntityTypeMap command-line option 82-9

-- command-line option 5-3, 5-12, 5-14, 60-4 Simulation Object Editor 64-4

--additionalSystemScriptsDirectory command- line option 5-9

--alphaBits command-line option 5-3, 6-14

--antiAliasing command-line option 5-3, 6-14

--appDataDir command-line option 5-3, 5-9 Simulation Object Editor 64-4

--appIdRange command-line option 5-8, 5-9

--appNumber command-line option 5-7, 5-8, 5-9

--autoConnect command-line option 5-3

--backend command-line option 5-14

--col command-line option 60-4

--config command-line option 5-14

--countryCodesMappingFile command-line option 5-10

--daemon command-line option 5-10

--dataDir command-line option 5-3, 5-10 Simulation Object Editor 64-4

--defaultObjectTimeout command-line option 5- 8, 5-10

--defaultSimulationModelSet command-line option 5-3

--depthBits command-line option 6-14

--depthBuffer command-line option 5-3

--destAddrString command-line option 5-8, 5-13

--deviceAddress command-line option 5-8, 5-13

--diGuyAnimationsFile command-line option 5- 10

--diGuyCharacerDataFile command-line option 5-10

--dis command-line option 5-3

--disableCallbackQueue command-line option 5- 10

--disableDynamicTerrain command-line option 5- 3

--disableKDTrees command-line option 5-5

--disableParallelTick command-line option 5-10

--disPort command-line option 5-9, 5-13

--dispSetting command-line option 5-3

--disVersion command-line option 5-8, 5-13, 5-21

--doNotCheckPluginVersions command-line option 5-3

Simulation Object Editor 64-4

--doNotLoadVrfPlugins command-line option 5- 3, 5-10

Simulation Object Editor 64-4

--enableChannel command-line option 5-10

--enableLogFileTimestamps command-line option 5-3

--enableVSync command-line option 5-4

--encryptImages command-line option 60-4

--entDispSetting command-line option 5-4

--entityDefsDir command-line option 5-4, 81-34

--entTypeMap command-line option 5-4

--envSetting command-line option 5-4

--execname command-line option 5-8, 5-13

--exerciseId command-line option 5-9, 5-13

--extendLevelZero command-line option 60-4

--extraArgs command-line option 5-3

--factoryRootDir command-line option 5-4

--federateName command-line option 5-8, 5-12

--federateType command-line option 5-8, 5-13

--fedFileName command-line option 5-7, 5-12

--file command-line option 60-4

--fileNotifyLevel command-line option 5-10


--fileTransporterReceivePort command-line option 5-4, 5-8

--fomMapperInitData command-line option 5-7, 5-12

--fomMapperLib command-line option 5-7, 5-12

--fomModules command-line option 5-8, 5-12

--forceTextShaping command-line option 5-4

--fowPerspective command-line option 5-4

--frameRate command-line option 5-4

--frontend command-line option 5-14

--frontEndPID command-line option 5-9

--fullScreen command-line option 5-4, 78-9

--fullyLoadTerrain command-line option 5-10

--generateFiles command-line option 60-5

--gui command-line option 5-4, 79-2

--guiArgs command-line option 5-14

--help command-line option 5-4, 60-5 Simulation Object Editor 64-5

--highestPriority command-line option 5-4

--hla13 command-line option 5-4

--hla1516 command-line option 5-4

--hla1516e command-line option 5-5

--hostAddressString command-line option 5-8, 5-

9, 5-10

--ignore_rest command-line option 5-3, 5-12, 60-

4

Simulation Object Editor 64-4

--ignoreZoomForSpeedtreeLod command-line option 5-7

--launcherLocation command-line option, Simulation Object Editor 64-5

--layoutSettingsFile command-line option 5-5 Simulation Object Editor 64-5

--level command-line option 60-5

--loadObservers command-line option 5-5

--loadPlugin command-line option 5-5, 5-10, 5-

17

Simulation Object Editor 64-5

--loadSimulationObjectGroup command-line option 5-5

--locale command-line option 5-4, 5-14 Simulation Object Editor 64-5

--localSettingsDesignator command-line option 5- 8, 5-13

--logFileName command-line option 5-5, 5-10

--mcastTtl command-line option 5-9, 5-13

--mergeEntityTypeMap command-line option 5-5

--mergeHierarchyEntityDef command-line option 5-5, 81-34

--mergeHierarchyTacticalGraphicsDef command- line option 5-5, 81-34

--mergeHierarchyUnitDef command-line option 5-5, 81-34

--mergeLeafEntityDef command-line option 5-5, 81-34

--mergeLeafTacticalGraphicsDef command-line option 5-6, 81-34

--mergeLeafUnitDef command-line option 5-6, 81-34

--mergeModelDefs command-line option 5-6, 81-

19

--mergeTacticalGraphicsTypeMap command-line option 5-6

--mergeUnitTypeMap command-line option 5-6

--mimModule command-line option 5-12

--missing command-line option 60-5

--msdlSIDCMappingFile command-line option 5- 11

--multicastAddresses command-line option 5-9, 5-

13

--noAppDataEntityDefs command-line option 5- 6, 81-34

--noAppDataEntityTypeMap command-line option 5-6

--noAppDataModelDefs command-line option 5- 6, 81-19

--noAppDataTacticalGraphicsDefs command-line option 5-6, 81-34

--noAppDataTacticalGraphicsTypeMap command-line option 5-6

--noAppDataUnitDefs command-line option 5-6, 81-34

--nonVrfObjectsUUIDScheme command-line option 5-6, 5-11

--noRtiCompilerCheck command-line option 5- 12

--notifyLevel command-line option 5-6, 5-11

--numCallbackThreads command-line option 5- 11

--opdEditorLocation command-line option, Simulation Object Editor 64-5

--outputLogFile command-line option 5-11

--plugin command-line option 5-6

--pseudoFullScreen command-line option 5-7, 78-

9

--publishMftOnly command-line option 60-5

--pvd command-line option 5-7

--recvBufferSize command-line option 5-9, 5-13

--regenerateAll command-line option 60-4


--row command-line option 60-6

--rprFomRevision command-line option 5-8, 5-13

--rprFomVersion command-line option 5-8, 5-13

--scenarioFile command-line option 5-7

--searchDir command-line option 60-5

--sendBufferSize command-line option 5-9, 5-13

--sessionId command-line option 5-8, 5-9

--setMainThreadToHighPriority command-line option 5-11

--settingsDirectory command-line option, Simulation Object Editor 64-5

--settingsFile command-line option, vrfSim 5-10

--showConsole command-line option 5-3 Simulation Object Editor 64-5

--simArgs command-line option 5-14

--simulationModelSet command-line option 5-11

--siteId command-line option 5-8, 5-9

--smsFile command-line option, Simulation Object Editor 64-5

--startMinimized command-line option 5-11

--stealth command-line option 5-7

--stencilBits command-line option 5-7, 6-14

--subDir command-line option 60-5

--subnetMask command-line option 5-9, 5-13

--suppressHatIntersectOnAttach command-line option 5-7, 50-6

--suppressSelfReflect command-line option 5-13

--synchronizeOcean command-line option 5-6

--targetFrameRate command-line option 5-12, 6-

17

--textureSize command-line option 60-6

--threads command-line option 60-5

--timeManagement command-line option 4-19, 5-

13, 5-19

--unbatchedRendering command-line option 5-5

--unplug command-line option 5-7

--useAbsoluteTimeStamps command-line option 5-7, 5-12

--useAdvisories command-line option 5-8, 5-12

--useAsyncIO command-line option 5-9, 5-13, 5-

20

--useFileCommChannel command-line option 5- 7

--useGeographicDdm command-line option 5-8

--useIpv6 command-line option 5-9, 5-13

--userDataDir command-line option 5-7, 5-12

--useReverseZBuffer command-line option 5-7

--version command-line option 5-7, 5-12, 5-14,

60-5

Simulation Object Editor 64-5

--visualTerrain command-line option, Simulation Object Editor 64-5

--vtFile command-line option 60-5

--waitQueue command-line option 5-12

-debug command-line option 5-14, B-11

-e command-line option 5-3

-G command-line option 5-14 Simulation Object Editor 64-5

-h command-line option, Simulation Object Editor 64-5

-K command-line option 5-5

-v command-line option, Simulation Object Editor 64-5

-Z command-line option 5-7

-z command-line option 5-7

B-- command-line option 5-14, B-11 F-- command-line option 5-14, B-11


Symbols

@dis comment 57-29

@dis navigation_lights 57-29


Numerics

-1 (wildcard) 69-7

2525B icon 83-2 2D

icon 16-9

changing 65-21

changing size 18-21

configuring 83-2

editing 83-2

label 18-11

scaling 18-21

using image for 65-22 label, shadow text 18-16

observer, attachment behavior 50-15 observer coordinate system 49-7 projection, switching to 3D 48-2 window 4-13

2D check box 65-25 2D icon, color 18-15

2D Icon model set 48-11 3D

model 16-9

changing 65-20

DI-Guy 29-5

licensing 1-21

observer coordinate systems 49-7


3D (continued)

projection, switching to 2D 48-2 window 4-13

3D Cartesian coordinate system 33-18 3D Colorized Models model set 48-11

color, changing 19-26 3D Models model set 48-11 3DS 80-5

ASCII Export 65-50

ASE 27-3

ASE file 65-47

file 52-3

3DS ASCII Export format 27-3 9-Line briefing 28-7


A

-A command-line option 5-8, 5-13, 5-20, 60-4

-a command-line option 5-7, 5-8, 5-9, 5-15 Abandon Plan command 36-42 abandoning plan 25-1, 36-42

confirmation prompt 26-6

abatis, constructing 31-12

absolute, pathname 12-7

Absolute mode 50-7 acceleration

displaying 18-11

specifying measurement unit 78-11

acceleration-to-rpm-factor parameter 9-18

accessibility check 21-6

action category 26-36, 32-8, 32-18

action table 68-4

actionCategories.tsk 26-36, 32-18 Activate Jammer task 31-4 activating

jammer 31-4

scenario event 8-10

scenario event from plan 8-11 activation, indirect fire 39-19 Activation set data request 40-3 active

sonar 9-17

stereo 77-20

tactical graphic 39-19, 40-3 Active Sonar Mode dialog box 34-5

Active Sonar Mode set data request 34-5 active-radar-sensor system 23-17

activity

adding 67-16

unit 34-6

Activity dialog box 34-6 Activity set data request 67-16 actuator 15-8, 15-9

indirect fire 72-14

missile-collision 72-12, 72-13

missile-maneuver 72-12, 72-13

warhead 72-17

warhead detonation 72-16

Add Conditional Expression dialog box 35-6 Add Group of Entities, dialog box 21-8

add image attribute 55-8

Add Model Definition dialog box 81-12 Add Props page 55-22, 63-9, 63-13, 63-20

Add Terrain Patch dialog box 55-6, 63-3, 63-21 Add Visualizer Definition Attribute window 81-30 adding

activities 67-16

attribute, visual definition 81-30 category 64-19, 64-20

Props Palette 83-14

channel 77-4

cockpit model 83-10

component to object in OPD Editor 70-8 default overlays 65-8

DI-Guy animation 68-4

DI-Guy character 68-3 entity bitmap image 83-9 entity to unit 24-7 environment condition 11-7

extended label 18-18

feature layer 52-4, 55-11

formation 66-9

global commands to plan 36-30 group of entities 21-8

image 65-24

key mapping 80-5

linked event 8-6

media to scenario event 8-5 model, visual 65-24

model definition 65-24, 65-25

model mapping 82-4

object, to Favorites list 16-27 object geometry 65-14

observer 48-6, 48-7

ocean layer 55-15, 55-16 parameter

model definition 81-15

schema 81-7 pedestrians, to crowd 29-3 plug-in 4-34


adding (continued) power type 72-23

prop 55-19

from feature layer 55-22 sensor component 71-11

sensor signature 71-5, 71-12

sensor type 71-9

slot 65-35, 65-36, 65-38

subordinate to unit 66-5

system to simulation object 65-30 terrain patch to terrain 55-5 terrain server 56-4

text, to title bar 78-10 text object 39-5

vertex 39-13

visual definition 81-26

window 77-2

additional-algorithm-config parameter 72-29 additionalDestinationAddresses parameter B-7 additional-opds parameter 12-6 additionalSystemScriptsDirectory parameter B-2 addMulticastAddr parameter B-7

adjusting, sound volume 47-3 advanced navigation 58-2

advisory message, enabling and disabling B-7 agent, contamination 23-7

aggregate, See also unit Aggregate As

dialog box 66-3

specifying a unit as option 66-3 aggregate warfare model 23-2, 67-3

aggregate-comms-jammer, system 23-16

aggregated state 24-9

aggregated unit 22-2 attack by fire 31-5

aggregate-formation-controller parameter 73-2

aggregate-level combat 23-7

entity, configuring 67-3

modeling 15-10

aggregate-level modeling 21-1 aggregate-level unit, parameter 67-4 AggregateLevel.sms 15-11, 23-2, 67-3

aggregate-object-param parameter 69-25 aggregate-param parameter C-8 aggregate-radar-jammer system 23-17

aggregateSpatialModelTickAsFastAsPossible-

WhilePaused parameter B-2

aggregateSpatialModelTickPeriod parameter B-2

aggregateSpatialModelTickPeriodUsesRealTime

parameter B-2 aggregateSpatialModelTickVariance parameter B-2 aggregation

automatic 24-12

manual 24-12

state 24-6

agility, terrain 1-12

aiming, sensor 34-38 Aiming dialog box 34-7 Aiming set data request 34-7 air, temperature 11-5

air corridor 39-4

air defense 31-6

air temperature, ambient 11-10 air traffic, generating 27-12 aircraft

attacking with gun 28-3 landing at airport 27-12

See also Fixed-Wing entity and Rotary-Wing entity

setting speed 34-29

strafing target 28-21

airlift 27-25

cargo 27-26

airport, landing aircraft at 27-12 airspace 39-4

Air-to-Ground Attack dialog box 31-4 Air-to-Ground Attack task 31-4

alias, attribute transformation 62-4 Allow Crossing dialog box 40-4 Allow Crossing set data request 40-4

allowed-state-repositories-types parameter 72-32

all-tasks-exclusive parameter 26-35

alpha 83-26

alpha bits 5-3 Altitude

condition 35-10

dialog box 34-8

set data request 34-8 altitude 18-10, 33-18

entity, displaying 18-23

fixed-wing entity 26-23

flying to 27-8, 27-10

intervisibility line 46-11

object, changing 19-5, 39-13

observer, filtering simulation objects by 6-9 ordering entity to 27-15

pasted object 16-24

route, setting 16-16


altitude (continued)

setting 16-14, 16-16, 34-8

fixed-wing entity 26-25 in dialog box 16-15 manually 16-15

specifying measurement unit 78-11 switching from 2D to 3D 48-2 testing entity for 35-10

vertex

changing 39-14

displaying 37-10 altitude point

changing color 53-6

deleting 53-5

inserting 53-5

Altitude set data request 26-25

Always Join Session with Open Database 4-17 Always Join Session with Session Database 4-17 ambient

color 43-4

occlusion map 1-15, 61-7

value, material 43-4

ambient air temperature 11-5, 11-10

ammo parameter 72-8

ammo select file 72-4, 72-33 ammo select table 72-8

counter measure 9-19

ammo-entry 72-17, 72-25

ammo-entry block 72-37

ammunition 23-13

amount 34-8

pacing and tracking 34-9 specifying amount 34-34

status 18-7

unit 67-5, 67-8 Ammunition dialog box 34-8

Ammunition Pacing/Tracking dialog box 34-9 Ammunition Pacing/Tracking set data request 34-

9

anaglyphic stereo 77-20

configuring 77-21

angle, damage 72-22, 72-26 Angle of Attack 83-12

angle-of-incidence parameter 72-22, 72-26

angleSegmentMax parameter 84-5 animated movement

configuring 65-47

movement file, configuring 65-51 Animated Movement dialog box 27-3, 65-52 Animated Movement task 27-3

animation attack 42-10

DI-Guy 5-10, 29-5

adding 68-4

choosing 68-5, 82-10

entity 27-3

fast roping 27-6

model 85-11

observer view transition 49-32 testing DI-Guy 35-11

Answer Questions button 33-23 anti-air

missile 31-5

resource 23-13

weapon 31-6

anti-aliasing 5-3, 6-14

anti-personnel 23-13 anti-ship

missile 31-5

resource 23-13

Anti-ship (Fixed Depth) task 28-14 anti-submarine, missile 28-12

anti-tank

ditch, improving 31-25

resource 23-13

anti-tank ditch, digging 31-13 Any, as condition parameter 36-22

Any Subordinate of Selected Aggregate check box 36-23

AOA updater 83-12

appData directory 5-9 appearance

bit 43-6

DI-Guy 5-10

random 65-17

pasting 16-23

power plant 9-17

setting 34-10

specifying for DI-Guy model 65-16 testing DI-Guy 35-11

Appearance dialog box 34-10 Appearance set data request 34-10 appending, saved views to view list 49-33 appIdRange parameter B-7

application

data, specifying location of 5-3, 64-4

ID 3-4

number 5-7, 5-8, 5-9, 7-41, 12-9

configuring B-2 default 5-15


application (continued)

number 5-7, 5-8, 5-9, 7-41, 12-9

specifying at startup 5-15

remote, notifying of VR-Forces run and pause 7-41

application ID 5-8

Application Settings dialog box 7-22, 24-11

File Caching Settings page 6-11, 61-2, 61-6

Key Mapping Editor page 80-4, 80-9 Mouse Mappings page 49-14 Performance Options page 6-15, 6-17 Script Options page 32-37

Session Options page 4-7, 7-10, 7-11, 7-12, 7-

22, 7-41, 49-22

Spot Report Options page 9-3, 9-5, 9-6, 9-8, 9-

9, 34-41

applying, platform update 64-19

appNumber parameter B-2 arc, segment 84-5

architecture, component 15-8

area 37-2, 37-5

creating for multiple entity creation 21-8 disaggregation 24-12, 37-2

dynamic terrain 59-3

extruded 35-12, 39-4 feature, list of 53-14 fill style 39-17

fortified, constructing 31-18

hazard 23-8

high fidelity damage 72-29 NBC 23-7

pedestrian 21-9

suppressive fire at 26-32, 28-17

terrain draw 53-18

terrain page-in 37-2, 56-6

areal, feature 57-12

Arm Mine at Depth task 28-3 Armed dialog box 34-11 Armed set data request 34-11 arming

IED 34-11

mine, naval 28-3

armor-piercing power domain 72-18 arrow

adding to line 39-17

forward and back 65-46, 66-7

freehand line 39-2 sensor contact line 42-15

Arrowhead Style dialog box 40-4 Arrowhead Style set data request 40-4

articulated part 85-2, 85-7

attaching to 50-4

tasks for moving 30-11 artillery

Fire-for-Effect task 28-11

unit 31-27

ASCII Export file 65-47, 65-50

ASE file 65-47, 65-50

ASE format 27-3

Ask to Join Session 4-17 assembly 67-5, 67-10

adding to entity 67-13 creating 67-11

editing 67-12

removing 67-13 roll up rule 67-14 rolling up 67-15

assertOnBlockingTerrainCalls parameter 52-8, B-2

assigning

echelon ID 15-7

plan to multiple simulation objects 36-39 session ID 4-8

asynchronous I/O 5-20, B-8 using for performance 6-12

atlas, texture 83-19

attach 50-7

observer, articulated part 50-4

Attach Components to Remote Entities On parameter 7-5

attach mode 1-14, 49-3, 49-8, 50-7

2D behavior 50-15

Absolute 50-7

Follow 50-8

Mimic 50-9

Mimic Location Track 50-10 Mimic Track 50-10

movement, attached context 49-8 prop, affect of 50-6

Space Follow 50-11

Tether 50-12

Tether Location Track 50-13 Tether Track 50-13

Track 50-14

Attach Object to Mouse check box 16-18 attached, context 49-8

Attached Near Clip Altitude, attribute 77-10 attaching observer

to object, with keyboard 50-3

to simulation object or prop 50-2


attachment

list, filtering 50-5

order 50-3

preservation of view changes 50-3 Attachment Panel 50-2

filtering attachment list 50-5 attack

air-to-ground 31-4

animation 42-10

anti-air missile 31-5

indicator 42-10

limited munition 23-7

missile 23-7

Attack Aircraft with Guns task 28-3 Attack By Fire dialog box 31-5 Attack By Fire task 31-5

attack parameter, edting 67-22

Attack with Anti-Air Missile dialog box 31-5 Attack with Anti-Air Missile task 31-5 attack with anti-ship missile 31-5

Attack with Anti-Ship Missile dialog box 31-5 Attack with Anti-Ship Missile task 31-5

Attack with Land-Attack Missile dialog box 31-6 Attack with Land-Attack Missile task 31-6 Attack with Torpedo dialog box 31-6

Attack with Torpedo task 31-6 attribute

Attached Near Clip Altitude 77-10 BOYSHP 57-24

buoy 57-24

building model definition 57-24 cockpit updater 83-10

COLOUR 57-24

COLPAT 57-24

DESIGNATOR 57-26

destroyedsymbol 83-8

Dynamic Near Clip Attached Policy 77-10 Dynamic Water Visibility Enabled 77-16 Dynamic Water Visibility Maximum 77-16 earth file, differential processing 57-21 feature 62-4

Fixed Near Clip 77-10

Fixed Near Clip When Attached 77-10 image 55-8

imagesymbolmap 83-7, 83-9

itemname 79-2, 79-6

light characteristic 57-31

LITCHR 57-31

MAK_EARTH_FILE 62-4

MAK_LAYER 62-4

attribute (continued) MAK_SOURCE_FILE 62-4

marker-scale 83-24

menuname 79-2

modeldefinitionschema 83-6 Near Far Clip Policy 77-10 OBJNAM 57-26

parent 83-6

Reduce Z Fighting Ratio 77-10 sensor 77-7

setting simulation object 34-10 SIGGRP 57-31

signal group 57-31

signal period 57-31

SIGPER 57-31

SIGSEQ 57-31

TOPSHP 57-30, 57-31

transformation, alias 62-4

transforming 62-4

type 83-6

visual definition 81-27

adding 81-30

WidgetTheme 83-6

window 77-6 attrition

rate 23-3

unit 23-10

audio 47-2

adding to scenario event 8-5

Audio Settings dialog box 47-2, 47-3, 47-5, 47-6,

47-7, 47-9

Audio Settings page 47-2, 47-3

authentication, proxy 56-5

Auto Generate 55-20

Auto Launch dialog box 34-13 automatic

aggregation 24-11

aggregation and disaggregation 24-12 attachment 39-11

counter measures 9-19

embarkation 19-10

laser 34-25

reorganization 34-33 running of scenarios 7-36

Automatic Air Defense task 31-6 Automatically Join Session 4-16 Automatically Open Session Database without

Joining Session 4-16

autonomous lasing 9-16

auto-reorganize parameter 12-5


Avoid Roads 34-28

avoidance, collision 3-16, 34-12 avoiding

collisions, obstacles, and features 19-16 objects 73-5


B

-B command-line option 5-9, 5-14, 7-39

back arrow 65-46, 66-7

back-end 3-2

balancing load 7-19 configuring feature data 55-11 console B-3

dropping from exercise 3-7

enabling time management 4-19, 5-19

feature representation 52-5 heartbeat B-5

late joining 3-7 mapping objects to 12-9 missing 3-8

multiple 3-2, 3-7, 12-9 reloading OPD B-3 remapping 3-8

in batch mode 7-39 sending messages 3-3

starting 4-3

as daemon 5-10

synchronizing 4-17 background

2D label 18-16

intervisibility information 46-11

background process 31-31, 32-5, 33-30 balancing, object load 7-19

ballistic gun, controller descriptor 72-8 ballistic missile 10-8

firing 10-8

movement, configuring 65-48 movement file, configuring 65-51 scripted movement 65-47

target event 10-10

Ballistic Missiles dialog box 65-48, 65-52 barbed wire, constructing 31-14 barricade, constructing 31-14

batch file 7-36

command-line option 5-9 configuring B-2

editing 7-37

batch mode 7-36, 7-37

remapping 7-39

batch mode (continued)

starting from command line 7-39 batchScenarioFileName parameter B-2 beacon 57-31

model definition 57-24

seasonal 57-30

streaming 57-23, 57-28

topmark 57-31

wake 11-19 bead

DOF 85-7

switch 85-8

beam 34-33

emitter 9-17, 34-18 standard and tracking 34-18

bearing, intervisibility line 46-11 behavior

scripted 27-3

simulation object 15-10

Behavior Set 32-9 assigning to force 26-21 creating 26-20

script availability 32-19, 32-21

berm, constructing 31-15

best practice, model design 83-26 binary key mapping 80-4

binding, system definition file variable 69-21 Biological Attack dialog box 31-7

Biological Attack task 31-7

biological contamination 23-7, 23-8, 31-7 bit

depth 5-3

depth and stencil 6-14 bitmap 52-4

adding new 83-9

adding to scenario event 8-5 displaying 55-7

icon 83-4

location of 2-4

blend image attribute 55-8 block

ammo-entry 72-37

damage-by-munition-power 72-21

damage-model 72-21, 72-25, 72-37

determinant 72-22

high-fidelity-terrain-damage-table 72-29

munition 72-18

power-list 72-18

standard-terrain-damage-table 72-28

blur 45-2, 45-4


BMP 52-4

body coordinates 49-3

bomb 72-17

dropping 28-18

laser guided 28-18

target 28-7

Bomb Location dialog box 31-8 Bomb Location task 31-8

bomb-bay weapon system 72-17 booby trap

creating 31-15

destroying 31-22

improving 31-24

boolean, operator 35-14

boom, refueling 30-12, 30-13

border, icon 18-20

Boundary Generation Tool 57-14 running 57-16

using 57-15

boundary.txt 57-15 bounding box

selecting objects 17-5

unit 66-11

bounding volume 19-16, 65-25

simulation objects 18-30, 18-31

specifying 65-10

unit, color 25-11

Bounding Volume check box 65-25 box

drawing 39-3

extruded 39-4

resizing 39-15

BOYSHP, attribute 57-24

breach, improving 31-25

Breach Obstacles dialog box 31-9 Breach Obstacles task 31-9 breaching

fortification 31-9

obstacle 31-9

breaking, wave 11-21

bridge 16-26, 65-9

building 31-16

destroying 31-22

improving 31-25

brightness 45-4 broadcasting

state update 48-11

stealth position and orientation 48-12 buffer, size 5-9, 5-13

building 16-26, 65-9

avoiding 19-16

bridge 31-16

conditional statement 36-11 creating entity in 19-4

ditch 31-17

dry gap 31-17

extruded 57-13

fortified area 31-18

prop type 55-26

setting avoidance 34-12

terrain 55-5

bump map 1-15, 61-7 buoy

attributes 57-24

daymark 57-30

designator 57-26

model definition 57-23, 57-24 using texture atlas 57-27

seasonal 57-30

signal sequence 57-31

streaming 57-23

topmark 57-31

unique 57-26

wake 11-19 buoyancy

enabling or disabling 44-7 LOD distance 44-7

burst

length 20-8, 20-12

period 20-8, 20-12

spawn 20-8

spawn pattern 20-12 button

Answer Questions 33-23

common for model definitions 78-9 Joystick 75-6

Key Mapping 75-7

toolbars 4-11


C

-C command-line option 5-3, 5-14

-c command-line option 5-9, 60-4 C++

scripted task 32-25

task 32-3, 33-15

cache

clearing 61-6

clearing model instancing 6-11


cache (continued) model instance 6-11

caching

earth file, offline 61-5 file 61-2

terrain data 1-18 terrain server data 61-3

calculating, support point 65-12 calculating damage 72-17 camera

effects 45-2

jitter 49-27

moving 49-13

position and orientation 77-19 shaking 49-27

ways to move 49-12

Camera Orientation Offset 77-7 Camera Position Offset 77-7, 77-19

can-be-radar-jammed parameter 23-17

canceling, reactive task 26-18

cancelling, generation of navigation data 58-8

can-pivot parameter 27-28 Capabilities dialog box 34-11 Capabilities set data request 34-11 capability, setting 34-11

car bomb, detonating 34-15 cargo

carrying 27-25

embarking 27-26

unloading 27-27 cargo door

closing 30-11

opening 30-13

carrier, placing entity on 19-4

Cartesian, coordinate system 33-18, 33-20

CAS 28-7

strafing target 28-21

catastrophic-kill parameter 72-26 Categories, clearing list 65-9 Categories list 65-9

category

action 32-8, 32-18

adding 64-19, 64-20

changing 65-3

echelon 15-6

object, changing 65-3

Object Group 16-25

Props Palette, adding 83-14 removing 64-19, 64-20

renaming 64-19, 64-21

category (continued) undoing changes 64-21

weapon and ammunition, adding 67-26 CDB database 57-17

CEO. See combat engineering object certainty level for spot reports 9-8 cgfDispatcherReceivePort parameter B-2 chaff 28-13

launching 9-19

Change Hostility dialog box 9-12 Change MOPP Level dialog box 31-10 Change MOPP Level task 31-10, 34-27 Change Posture dialog box 31-11 Change Posture task 31-11, 34-30 changing

2D icon 65-21

2D icon image 65-22 3D model 65-20

altitude, vertex 39-14

channel attributes 77-7 color

altitude point 53-6

force 19-26

tactical graphics 39-16

colorized model 65-20

component priority 70-9

control object 39-12 entity

category 65-3

enumeration 65-4

parameter 65-12

entity name 19-5

extended label index 18-19 field of view 77-14

force hostility 9-10 frame rate mode 12-6 gain 49-30

grid spacing 66-14

icon size 18-21

image display order 55-10 intervisibility object 46-8

key mapping 80-7

line, direction 39-16

model definition, prop 63-23 model set 48-11

MOPP level 31-10

name, tactical graphic 19-6 object category 65-3

observer mode 48-3

overlay name 38-4


changing (continued) posture 31-11, 34-30 prop

model definition 55-26 position or orientation 55-26 type 55-26

simulation object, name 65-7

Simulation Time Scale Toolbar range 7-25 site ID 12-9

spot report icon 65-23 subordinate order 66-6

terrain database for scenario 12-8 unit of measurement 78-11

unit state 24-11

runtime 24-10

viewport 77-15 width of line 39-17

window attributes 77-6 channel

adding 77-4

attribute, sensor 77-7

changing attributes 77-7

keyword 77-7

compass 49-5

multiple 77-17

observer 48-6

projection resize policy 77-11 property 77-7

removing 77-5

sound mapping 47-8

Channel Name 77-7

ChannelKeyword parameter 83-12 character

DI-Guy 5-10

adding 68-3

specifying for DI-Guy model 65-16 character_animations_table.mtl 68-3 check box

2D 65-25

Bounding Volume 65-25 Color by Force Type 18-15 Daylight 65-25

Display Models 65-25

Marker Labels 65-25, 65-31 checking

version, plug-in 5-3

checking waypoint accessibility 21-6 checkpoint 7-27, 7-30

deleting 7-33

disabling periodic 7-32

checkpoint (continued) periodic, scheduling 7-32 rolling back to 7-25 saving 7-30

saving from snapshot 7-31 scenario 7-30

Checkpoint Settings page 7-26, 7-32, 7-33, 7-34 Chemical Attack dialog box 31-11

Chemical Attack task 31-11

chemical contamination 23-7, 23-8, 31-11 child, element definition 81-21

choosing, window layout 78-5 chop, wave 11-16

choppiness, ocean 11-18

CID level 9-13

for firing at target 9-15 icon, color 9-13

circle, extruded 39-4

circling, point 27-23

civilian, creating 21-2 Civilian Idle task 29-2

civilian visit point 21-9, 21-10 clamp image attribute 55-8

clamp to border image attribute 55-8 clamp to edge image attribute 55-8 clamping, entities 19-20

class

DtSimComponentManager 69-9

DtSimObjectNetInterface 69-9

DtSimObjectStateRepository 69-9

DtSimTaskManager 69-9

DtVrfObject 69-9

FeatureSet 33-3

Location3D 33-18

Lua 33-3

SimObject 33-4

Vector3D 33-18

VectorGeoc3D 33-20

VectorOffset3D 33-20

vrf 33-4

VR-Forces 69-3 Classified CID level 9-13 clearing

default window layout 78-6 file cache 61-6

model instancing cache 6-11 object console 18-35

snapshot list 7-34

Used By Countries list 65-9 view list 49-32


click to create 16-11

click to locate 16-11, 16-13

climb rate 27-10

clipboard 18-35

clipping plane 83-22

adjusting when creating simulation objects 19-4 clock mode 3-11, 12-6

close air support 28-7, 31-4

strafing 28-21

Close Cargo Door task 30-11 Close Door task 29-2

Close Window task 29-2 closing

all windows 4-24

application 4-24

cargo door 30-11

Create Object dialog box 16-13 door 29-2

formation 22-5

simulation 7-27

simulation engine 4-24

window 29-2 cloud

cover 11-5, 11-8, 11-12

disabling 43-18

skybox cube map 43-14 smoke 28-13

cockpit display 51-6, 82-2, 83-10

adding new 83-10

element definition 81-21 enabling or disabling 51-3 installing 83-11

model definition, creating 83-11 updater 83-10

attribute 83-10

Cockpit Display Settings page 51-5 code

country B-2 laser 34-26

assigning 9-15

coefficient probability 72-9

coefficients determinant 72-23 collapsing

unit 25-2, 25-3

to root 25-3

collateral damage 72-37

probability table 72-10

collision avoidance 3-16, 19-16

configuring 73-4 specifying for entity 34-12

Collision Avoidance Types dialog box 34-12 Collision Avoidance Types set data request 34-12 color

2D icon 18-15

2D label background 18-16 altitude point

changing 53-6

deleting 53-5

inserting 53-5

ambient 43-4

compass 49-5

diffuse 43-4

emitter volume, pulse rate 84-2 entity label 18-9

fog 11-5, 11-11

force, changing 19-26, 64-23

intervisibility, configuring 46-9

partially identified simulation objects 9-13 pattern 57-24

radio communication line 42-23 represents emitter volume frequency 84-2 sensor contact line 42-15

specular 43-4

squawk indicator 42-23 tactical graphic vertex 39-17

tactical graphics, changing 39-16 terrain, configuring 53-5

unit bounding volume 25-11 Color by Force Type check box 18-15 Color dialog box 40-4

Color set data request 40-4 coloring

draw call 6-18

terrain 53-4

colorized model, changing 65-20 COLOUR attribute 57-24

COLPAT attribute 57-24

combat 23-2

aggregate-level 23-7

power 23-3

unit 24-10

graphics 42-10

combat engineering object 23-9 as feature 62-10

completion percentage, setting 34-29 configuring 67-25

creating 23-11

creating new model 67-3 partial completion 23-12 rate of creation 23-12


combat engineering object (continued) status 23-12

combat identification level 9-13 combined mode, vrfLauncher 5-15 combining, key mapping 80-8 Come to Stop task 27-4

command

Abandon Plan 36-42

Delete Self 20-9

Disembark 19-11

Embark On 19-9

global, adding to plan 36-30 Issue Plan 36-34

menu, configuring 79-2

Restart Plan 36-41 command line

loading scenario from 7-18 loading terrain 5-7

options 5-3

command-line, Simulation Object Editor 64-4 command-line option 5-1

-- 5-3, 5-12, 5-14, 60-4

-A 5-8, 5-13, 5-20, 60-4

-a 5-7, 5-8, 5-9, 5-15

--additionalSystemScriptsDirectory 5-9

--alphaBits 5-3, 6-14

--antiAliasing 5-3, 6-14

--appDataDir 5-3, 5-9

--appIdRange 5-8, 5-9

--appNumber 5-7, 5-8, 5-9

--autoConnect 5-3

-B 5-9, 5-14

B-- 5-14, B-11

--backend 5-14

-C 5-3, 5-14

-c 5-9, 60-4

--col 60-4

--config 5-14

--countryCodesMappingFile 5-10

--daemon 5-10

--dataDir 5-3, 5-10

-debug 5-14, B-11

--defaultObjectTimeout 5-8, 5-10

--defaultSimulationModelSet 5-3

--depthBits 6-14

--depthBuffer 5-3

--destAddrString 5-8, 5-13

--deviceAddress 5-8, 5-13

--diGuyAnimationsFile 5-10

--diGuyCharacerDataFile 5-10

command-line option (continued)

--dis 5-3

--disableCallbackQueue 5-10

--disableDynamicTerrain 5-3

--disableKDTrees 5-5

--disableParallelTick 5-10

--disPort 5-9, 5-13

--dispSetting 5-3

--disVersion 5-8, 5-13, 5-21

--doNotCheckPluginVersions 5-3

--doNotLoadVrfPlugins 5-3, 5-10

-E 5-4

-e 5-3, 60-4

--enableChannel 5-10

--enableLogFileTimestamps 5-3

--enableVSync 6-19

--enableVSync 5-4

--encryptImages 60-4

--entDispSetting 5-4

--entityDefsDir 5-4, 81-34

--entTypeMap 5-4

--envSetting 5-4

--execname 5-8, 5-13

--exerciseId 5-9, 5-13

--extendLevelZero 60-4

--extraArgs 5-3

-F 5-4, 5-14

F-- 5-14, B-11

-f 5-7, 5-12, 5-18, 60-4

--factoryRootDir 5-4

--federateName 5-8, 5-12

--federateType 5-8, 5-13

--fedFileName 5-7, 5-12

--file 60-4

--fileNotifyLevel 5-10

--fileTransporterReceivePort 5-4, 5-8

--fomMapperInitData 5-7, 5-12

--fomMapperLib 5-7, 5-12

--fomModules 5-8, 5-12

--forceTextShaping 5-4

--fowPerspective 5-4

--frameRate 5-4

--frontend 5-14

--frontEndPID 5-9

--fullScreen 5-4, 78-9

--fullyLoadTerrain 5-10

-G 5-4, 5-14, 5-16

-g 60-5

--generateFiles 60-5

--gui 5-4, 79-2


command-line option (continued)

--guiArgs 5-14

-H 5-8, 5-9

-h 5-4, 5-10, 5-14, 60-5

--help 5-4, 60-5

--highestPriority 5-4

--hla13 5-4

--hla1516 5-4

--hla1516e 5-5

--hostAddressString 5-8, 5-9, 5-10

-I 5-5

-i 4-8, 5-8, 5-9, 5-10

--ignore_rest 5-3, 5-12, 60-4

--ignoreZoomForSpeedtreeLod 5-7

-K 5-5

-L 5-5, 5-10

-l 5-5, 60-5

--layoutSettingsFile 5-5

--level 60-5

--loadObservers 5-5

--loadPlugin 5-5, 5-10, 5-17

--loadSimulationObjectGroup 5-5

--locale 5-4, 5-14

--localSettingsDesignator 5-8, 5-13

--logFileName 5-5, 5-10

-m 60-5

--mcastTtl 5-9, 5-13

--mergeEntityTypeMap 5-5

--mergeHierarchyEntityDef 5-5, 81-34

--mergeHierarchyTacticalGraphicsDef 5-5, 81-

34

--mergeHierarchyUnitDef 5-5, 81-34

--mergeLeafEntityDef 5-5, 81-34

--mergeLeafTacticalGraphicsDef 5-6, 81-34

--mergeLeafUnitDef 5-6, 81-34

--mergeModelDefs 5-6, 81-19

--mergeTacticalGraphicsTypeMap 5-6

--mergeUnitTypeMap 5-6

--mimModule 5-12

--missing 60-5

--msdlSIDCMappingFile 5-11

--multicastAddresses 5-9, 5-13

-N 5-7, 5-8, 5-12

-n 5-6, 5-11, 5-16

--noAppDataEntityDefs 5-6, 81-34

--noAppDataEntityTypeMap 82-9

--noAppDataEntityTypeMap 5-6

--noAppDataModelDefs 5-6, 81-19

--noAppDataTacticalGraphicsDefs 5-6, 81-34

--noAppDataTacticalGraphicsTypeMap 5-6

command-line option (continued)

--noAppDataUnitDefs 5-6, 81-34

--nonVrfObjectsUUIDScheme 5-6, 5-11

--noRtiCompilerCheck 5-12

--notifyLevel 5-6, 5-11

--numCallbackThreads 5-11

-O 5-6

--outputLogFile 5-11

-P 5-9, 5-13, 5-20

-p 5-8, 5-13, 60-5

--plugin 5-6

--pseudoFullScreen 5-7, 78-9

--publishMftOnly 60-5

--pvd 5-7

-q 5-11

-r 5-11, 60-5

--recvBufferSize 5-9, 5-13

--regenerateAll 60-4

--row 60-6

--rprFomRevision 5-8, 5-13

--rprFomVersion 5-8, 5-13

-S 5-7, 5-8, 5-13, 5-20, 50-6

-s 5-11, 5-15, 60-5

--scenarioFile 5-7

--searchDir 60-5

--sendBufferSize 5-9, 5-13

--sessionId 5-8, 5-9

--setMainThreadToHighPriority 5-11

--settingsFile 5-10

--showConsole 5-3

--simArgs 5-14 Simulation Object Editor

-- 64-4

--appDataDir 64-4

--dataDir 64-4

--doNotCheckPluginVersions 64-4

--doNotLoadVrfPlugins 64-4

-G 64-5

-h 64-5

--help 64-5

--ignore_rest 64-4

--launcherLocation 64-5

--layoutSettingsFile 64-5

--loadPlugin 64-5

--locale 64-5

--opdEditorLocation 64-5

--settingsDirectory 64-5

--showConsole 64-5

--smsFile 64-5

-v 64-5


command-line option (continued) Simulation Object Editor

--version 64-5

--visualTerrain 64-5

--simulationModelSet 5-11

--siteId 5-8, 5-9

--startMinimized 5-11

--stealth 5-7

--stencilBits 5-7, 6-14

--subDir 60-5

--subnetMask 5-9, 5-13

--suppressHatIntersectOnAttach 5-7, 50-6

--suppressSelfReflect 5-13

--synchronizeOcean 5-6

-T 5-12

-t 60-5

--targetFrameRate 5-12, 6-17

--textureSize 60-6

--threads 60-5

--timeManagement 4-19, 5-13, 5-19

-u 60-5

--unbatchedRendering 5-5

--unplug 5-7

--useAbsoluteTimeStamps 5-7, 5-12

--useAdvisories 5-8, 5-12

--useAsyncIO 5-9, 5-13, 5-20

--useFileCommChannel 5-7

--useGeographicDdm 5-8

--useIpv6 5-9, 5-13

--userDataDir 5-7, 5-12

--useReverseZBuffer 5-7

-v 5-7, 5-12, 5-14, 60-5

--version 5-7, 5-12, 5-14, 60-5

--vtFile 60-5

-w 60-6

--waitQueue 5-12

-x 5-8, 5-9, 5-13, 5-17, 60-6

DIS 5-21

-Z 5-7

-z 5-7

comma-separated values file 10-8 comment

@dis 57-29

MTL parameter A-3

comm-model-name parameter 74-4

commModelParams.mtl file 13-3, 74-4 communication

component 15-8

line 42-20

line-of-sight 42-22

communication model 13-2, 74-4

custom 15-8

external 15-7

setting 13-3

simulation object 15-7

communications, jamming 23-16

company, pre-configured 24-5

comparison operator 35-13 compass

color 49-5

configuring 49-5

location 49-5

model definition 49-5

observer 49-4

compiling, incremental 6-12

component 69-8

actuator 15-9

adding to object in OPD Editor 70-8 architecture 15-8

attaching to remote entities 7-5 attaching to remote entity 76-2 communication among 15-8

controller 15-9

creating connection in OPD Editor 70-10 deleting in OPD Editor 70-7

descriptor, elements of 69-13 emitter 34-18

entity 69-13

priority 70-9

sensor 15-9

simulation object 69-13

systems 69-17

tuning 6-13

performance 6-13 component attachment table 76-2

Component Attachment Table parameter 7-6 Component Manager C-5

Component Visualization 61-8

Component-Attachment parameter 12-5

Component-Attachment-Table parameter 12-5

componentAttachmentTable.mtl 76-2

component-descriptor-type 69-13 component-manager parameter C-5, C-7 component-type 69-13

composing, terrain 52-2

compressing, model and image files 83-27 compression, texture 61-6

computed route, creating 39-7 Concealed dialog box 34-13 Concealed set data request 34-13


concealment, setting 34-13

concurrent task 25-1, 26-5, 32-18 condition

considerations for using 35-10 Detect Entity 35-10

Engineering Object Breached 35-10 Entity Altitude 35-10

Entity Destroyed 35-10

Entity Di-Guy Animation Check 35-11 Entity Di-Guy Appearance Check 35-11 Entity Embarked 35-11

Entity Has Target 35-11 Entity In Area 35-12, 39-4 Entity Left of Line 35-12 Entity Under Fire 35-12 If, creating 36-5

Lifeform Surrendered 35-12 Missile Approach Warning 35-12 name 36-23

name condition, pattern 36-22 pattern 36-24

editing CSV file 36-24 Random 35-13

Receive Text Message 35-13 Resource 35-13

Scenario Event 35-13

Simulation Date/Time 35-14

Simulation Time 35-13

Tactical Graphic Active 35-14, 39-19, 40-3

While 35-9

conditional expression dialog box 36-11 conditional statement 35-4

building 36-11

filtering simulation object list 26-10 trigger 35-7

condition-entity-types.csvfile 36-24

configName parameter 83-19, 83-21 configuration

display engine 77-2

loading 77-5

saving 77-5

entity display 5-4

environment 5-4 file

condition-entity-types.csv 36-24

RTI 2-9

joystick, favorite 75-14

plug-in, deleting 4-36 simulation model set 7-9

configuration file

character_animations_table.mtl 68-3

commModelParams.mtl 13-3, 74-4

feature 62-6

for object parameter database 64-5 navigation area 58-10

sysdef 69-17 vrfSim.mtl B-2 vrfSimSettings.xml 6-15

configuring

2D icon 83-2

aggregate-level entity 67-3 back-end

console B-3 heartbeat B-5

ballistic missile movement 65-48 batch file B-2

combat engineering objects 67-25 communication model 13-2

compass 49-5

condition pattern enumerations 36-24 context-sensitive menu 79-5

contour lines 53-10

counter measures 9-19

Create Object dialog box 16-13 damage-by-power 72-18

depth of field 49-25 destination address B-7 detection tables 9-13 dialog box

information 79-3

pages 79-3

DI-Guy B-3, B-6

character and appearance 65-16, 68-3 direct fire weapon 72-4

DIS B-7

display 5-3 drainInput B-4

for DIS B-7 for HLA B-6

earth file 57-3

embarkation 65-34

slot 65-36, 65-38

embedded entity 19-13

emitter 74-2

emitter volume 84-2

segments 84-4 exercise ID B-7

external communication model 13-3 feature avoidance 73-5


configuring (continued) feature data 62-2 FED file name B-6

federation execution B-6 name B-6

fixed weapon system 72-16 FOM Mapper B-6 formations 73-2

frequency of data sends B-3 GDB soil type 53-2

grid lines 53-8

ground clamping 19-22

GUI elements 79-2 heartbeat threshold B-7 HLA B-6

hostility 9-10

IED 34-15

ingress and egress points 65-36 instrument panel 51-7

interest management 6-9

intervisibility objects 46-9

joystick 75-2

keyboard entity control 75-2 map datum B-6

menu 79-2

model definition 81-9

movement file 65-51 multicast address B-7 multichannel display 77-17 mutually exclusive tasks 26-35 object avoidance 73-5

obstruction avoidance 73-4 ocean planar reflection 43-10 orientation clamping 19-22 path, to OPD file B-3

port number B-7

power of detonation 72-19 projection resize policy 77-11 props 52-4

pulse rate 84-2

radio message model 13-2 radios 74-4

range rings 18-27 receive port B-2

right-click menu 79-5

rotary-wing lateral movement 26-32 scenario file to use B-4

schema 81-4

sensor contact line 42-15 sensor effects 45-4

configuring (continued) sensors 71-2

session 4-16 ID B-4

shadows 43-21

ship wakes 83-14

signature propagator 71-9 simulation management message B-5 site ID B-5

slot exclusion 65-40 start mode B-5 stereo

anaglyphic 77-21

polarized 77-22 system for MÄK RTI 2-9 terrain color settings 53-5 terrain database

path B-3 to load B-6

terrain profile 54-3

time management 4-18 time stamp order B-7 toolbar 79-6

tracers 72-8

track history 42-6

unit, ammunition, weapons, equipment 67-5 visual quality slider 6-16

VR-Forces for external communications effects server 13-2

confirmation prompt

plan, enabling or disabling 26-6 task, enabling or disabling 26-6

connecting, to network automatically 5-3 connection

component 70-10

configuring in system definition file 69-18 information 4-31

sensor 71-3

simulation object group 65-46 Connection Information dialog box 4-31 console

configuring for back-end B-3 messages

sending 36-33

sent to 5-16

object 18-31

setting notification level 34-28 constrained, time 4-17

constraint 50-7

view 49-28


Construct Abatis dialog box 31-12 Construct Abatis task 31-12

Construct Anti-Tank Ditch dialog box 31-13 Construct Anti-Tank Ditch task 31-13 Construct Barbed Wire dialog box 31-14 Construct Barbed Wire task 31-14

Construct Barricade dialog box 31-14 Construct Barricade task 31-14 Construct Berm dialog box 31-15 Construct Berm task 31-15

Construct Booby Trap dialog box 31-15 Construct Booby Trap task 31-15 Construct Bridge dialog box 31-16 Construct Bridge task 31-16

Construct Dry Gap dialog box 31-17 Construct Dry Gap task 31-17

Construct Fortified Area dialog box 31-18 Construct Fortified Area task 31-18 Construct Fortified Line dialog box 31-19 Construct Fortified Line task 31-19 Construct Minefield dialog box 31-20 Construct Minefield task 31-20 Construct Strong Point dialog box 31-21 Construct Strong Point task 31-21 constructing

abatis 31-12

barbed wire 31-14

barricade 31-14

berm 31-15

fortified line 31-19

strong point 31-21

terrain 55-5 contamination

agent 23-7

biological 31-7

chemical 31-11

nuclear 31-29

nuclear, biological, chemical 23-7, 23-8

type, setting 34-13 Contamination dialog box 34-13

Contamination set data request 34-13 context-sensitive menu 78-9

configuring 79-2, 79-5 contour line

displaying 53-9

spacing 53-10

thickness 53-10

Contour Lines page 53-9, 53-10

contrail 42-3

contrast 45-4

control, remote 1-16 control object 37-2, C-7

concepts 37-2

copying 16-21

count of 18-36

creating 16-3

editing 39-12

list of for scenario 12-10 name 37-2

parameter-type 69-26

pasting 16-21

pedestrian path 21-9, 37-2

selecting 17-4, 17-5

spot report 9-9

controller 15-8

component 15-9

detonation 72-16

dynamic-terrain-munition-damage 72-28

game 19-18

indirect fire 72-14

indirect fire weapon 72-14 joystick 75-2

lasing 72-13

launcher 72-13

making decisions and performing tasks 15-9 missile 72-12, 72-13

target selection 72-6, 72-11, 72-13 controlling

messages 5-16

remote 49-34 conventions, manual lvii convoy 27-4, 27-5

behavior 26-11

Convoy Along task 26-11, 27-4

Convoy To task 26-11, 27-5 coordinate

observer 49-3

point 53-16

UV 55-9

coordinate system 1-12

3D 49-7

3D Cartesian 33-18

Cartesian 33-18, 33-20 changing unit of 78-11 geocentric 52-6

supported 52-6 copying

formation 66-12

model definition 81-14

objects 16-21


copying (continued) performance and 16-21

plan statements 36-40

schema 81-6

scripted task 32-34

spawn pattern 20-14

corridor 39-4 count

object 18-36

simulation object 18-36

counter measure 28-13 ammo select table 9-19 launching 9-19

Counter Measures Auto Launch, set data request 9-19

Counter Measures Auto Launch set data request 34-13

country code B-2

countryCodesMappingFile parameter B-2, B-4 CPU time, giving up 6-17

crawling 34-31

Create Anti-Tank Ditch dialog box 31-13 Create Barbed Wire dialog box 31-14 Create Barricade dialog box 31-14

Create Berm dialog box 31-15 Create Booby Trap dialog box 31-15 Create Bridge dialog box 31-16 Create Connection dialog box 70-10 Create Dry Gap dialog box 31-17

Create Fortified Area dialog box 31-18 Create Fortified Line dialog box 31-19 Create global command 36-33

Create Indirect Fire dialog box 10-3 Create Intelligence Object dialog box 8-8 Create menu 16-3

assigning or removing simulation object 65-7 selecting object 16-8

Create Minefield (ADAM-RAAM) dialog box 31- 24

Create Minefield (Volcano) dialog box 31-20 Create Multiple Entities, dialog box 21-7 Create New Component dialog box 70-8 Create New Entity dialog box 65-32

Create New Entity Type Model Mapping dialog box 82-4

Create Object dialog box 16-3

Attach Mouse to Object 16-18 configuring 16-13

tab 16-11

Create Object dialog box 16-13 Create Pedestrians dialog box 21-3 Create Pedestrians task 29-3 Create Resource dialog box 70-11 Create Route dialog box 16-16

Create Scenario Event dialog box 8-3

Create Spawn Pattern dialog box 20-10, 20-14 Create Strong Point dialog box 31-21 Create_Global_Dynamic_Terrain parameter 12-6

Create_Global_Environment parameter 12-6 Created Object variable 35-15

create-script-id parameter 32-21

creating 16-9

aggregate-level entity 67-3 area for multiple entities 21-8 assembly 67-11

batch file 7-37

Behavior Set 26-20

booby trap 31-15

civilians 21-2

combat engineering object 23-11 component connection 70-10

computed route 39-7

control object 16-3

crowd 21-2

crowd unit 21-3

crowds 21-2

cultural feature 16-26, 65-9

demonstration recordings 36-35

element definition 81-24

embedded entity 30-14

entity 16-9, 19-3

adjusting clipping plane 19-4 fixed-wing 26-23

from existing 65-33

in buildings 19-4

new 65-32

fortified area 31-18

fortified line 31-19

freehand line 39-2

global plan 36-26

If block 36-5

indirect fire event 10-3 inset view 51-2

joystick configuration 75-4

key map 80-9

MEDF and MEIF files 83-27 minefield 31-20

model, guidelines for 83-26


creating (continued)

model definition 81-9, 81-12

cockpit display 83-11

navigation area 58-3

new scenario 7-3

object 16-3, 16-4, 16-5, 16-8, 16-11

in plan 36-33

mouse with 16-18

setting properties 16-13

objects 16-8

observer mode 48-4

overlay 38-3

pedestrian area 21-2

plans 36-3

prop 16-9, 16-26, 83-13

reactive task 32-27

scenario event 8-3

schema 81-5

script 32-6

scripted set 32-26

selection group 17-8

selection group from menu 17-9 simulation model set 64-17, 64-18

simulation object 16-3, 16-4, 16-8, 16-11, 19-3

from existing 65-33

group 65-45

multiple 21-5

simulation objects, multiple 21-2 sink points 20-4

snapshot 7-33

spawn pattern 20-10

spawn points 20-2

strong point 31-21

system definition file 69-17 tactical graphics 16-9, 39-2

terrain 55-3

text object 39-5

unit 24-2, 66-4

aggregation state 24-6

entity 24-2

user-defined formation 73-4

window layout 78-4

crepuscular ray 43-12

crosswalk 21-9

crouching 34-31 crowd

adding members 29-3

creating 21-2

dispersing 29-5

gathering around object 29-4

crowd (continued)

gathering at location 29-4 protesting 29-7

unit, creating 21-3

wander 29-8

Crowd Along Line dialog box 29-3 Crowd Along Line task 29-3 Crowd Around Location task 29-4 Crowd Around Object task 29-4

Crowd in Front of Entity dialog box 29-5 Crowd in Front of Entity task 29-5

cruise missile, firing 28-10 CSV, file 27-3

CSV file 10-8, 65-47, 65-50

configuring for ballistic missile or animated movement 65-51

CTDB file 52-3

cube map, recalculating 43-14 culling, face front 44-8 cultural feature 16-26, 65-9

aligning to gravity 65-15

creating 16-3, 16-4, 16-5, 16-8, 16-11

ground clamping 65-15

heading, setting 16-17

information 18-3

cultural-feature-param parameter 69-12, C-8 cultural-feature-state-repository 69-12 Current Speed dialog box 34-14

Current Speed set data request 34-14 cursor 16-9, 16-10

curvature of the earth display, mode 42-22

custom, plan 20-2, 20-9, 20-12

customizing, object parameter database 69-27 cut-in site 57-14


D

-d command-line option, vrfSim 5-10 daemon

running vrfSim as B-2 starting back-end as 5-10

daemon parameter B-2

damage

actuator 72-22, 72-26

calculating 72-17

collateral 72-37

dynamic terrain 72-28

file 69-26


damage (continued) model 65-28, 65-29

specifying 65-30

probability 72-21

probability table 72-10

damage file 72-4, 72-17, 72-21, 72-35, 72-37

damage-by-power 72-21

damage system 72-4, 72-10, 72-17, 72-34, 72-37

damage table 72-25

damage-by-ammo-type 72-10, 72-17, 72-25

example 72-36

damage-by-munition-power block 72-21

damage-by-power 72-10, 72-17, 72-24

adding new 72-23

configuring 72-18

damage file 72-21

terrain 72-28

damage-by-power-entry 72-21

damage-model block 72-21, 72-25, 72-37

dashed line 39-17 data

caching terrain 61-3

configuring frequency of sends B-3 directory 2-4

specifying location of 5-3, 64-4

elevation 52-3

feature, configuring 62-2

input 69-13

path 3-12

port 15-8

S-57 55-27

streamed, processing 57-7

synchronizing 4-23 data directory

back-end 5-10

user 5-12

data distribution management 6-8, 6-9

See also DDM database 52-6

CDB 57-17

large 52-7

loading 52-7

object parameter 69-2

paging 52-8

terrain 1-12

loading 4-19

provided 53-19

dataset, virtual and tiled 60-4 date 11-2

setting 11-2, 11-3

date (continued)

setting in new scenario 7-7 simulation 7-11

default 7-12

Date and Time page 11-3, 11-4 datumShiftX parameter B-3 datumShiftY parameter B-3 datumShiftZ parameter B-3 daylight, controlling light 43-7 Daylight check box 65-25

daylightControlledLights parameter 43-7

daylight-illumination parameter 71-13

daymark, buoy 57-30

daymark_attr_map.csv 57-30

daymark_layer_list.csv 57-30

daymark.dtxc 57-30

day-night-transition-time is parameter 71-13 DDM 6-8, 6-9

region size 6-9

DDS texture 61-6, 61-10

flipping 55-6, 83-21 Deactivate Jammer task 31-21 deactivating, jammer 31-21

dead-reckoning 6-16, B-4

debug mode, running from vrfLauncher 5-15 debugging

earth file 61-14 Navigation Lab B-3 shaders 61-8

terrain 61-12

decal effects 42-3, 82-2 enabling and disabling 42-4 models 42-4

decal image attribute 55-8 decay rate for spot reports 9-8 decision making 15-9

decreasing speed of navigation 49-28 default

formation 66-10

joystick configuration 75-14

name 16-11

plan 20-2, 20-9, 20-13

Set commands 34-4

settings, restoring 4-21 simulation model set 5-3

configuration 7-9

simulation model set configuration 7-11 spawn pattern 20-9

starting date and time 7-12 value, parameter 12-10


default (continued) view 49-32

default overlay adding 65-8

specifying 65-8

default_guiConfiguration.gui 79-2

default_guiSimpleScenarioPlayer.gui 79-2 DefaultEllipsoidArc, model definition 84-2 defaultHeartbeatThreshold parameter B-7 defaultObjectTimeout parameter B-7 DefaultObserverView parameter 12-6 defaultParameterDatabasePath parameter 12-7, B-3 defaultSpawnTemplates.mtl 20-9

default-task-rules.tsk 26-35, 32-18 defaultTerrainDatabasePath parameter 12-7, B-3 defense parameter, editing 67-23

defensive

measure 28-13

movement 31-28 definition

element 81-21

model, buoy 57-23, 57-24

parameter 70-4 degrees of freedom 85-7 delay parameter 72-29

Delete button 49-32

Delete Checkpoints dialog box 7-33

Delete Object global command 36-33, 36-34 Delete Self, command 20-9

Delete Self global command 36-34 deleting

altitude point 53-5

assembly 67-13

category 64-19, 64-20

channel 77-5

checkpoints 7-33

element definition 81-32

entity 19-5

from simulation model set 65-34 environment condition 11-8

extended label 18-19

intervisibility object 46-12

key map 80-9

key mapping 80-7

messages from object console 18-35 model definition 81-13

model mapping 82-7

object 65-34

in plan 36-33

object from selection group 17-10

deleting (continued) observer 48-9

mode 48-5

overlay 38-5

object 39-11 parameter

model definition 81-18

schema 81-8

parameters and components in OPD Editor 70- 7

plan statement 36-10 plug-in

configuration 4-36

XML file 4-37

scenario event 8-13

schema 81-6

script 32-34

selection group 17-10

simulation object 19-5

in plan 36-34

snapshots 7-34

spawn pattern 20-16

terrain, cached 61-6

trigger 36-9

unit 24-13

vertex 39-15

view 49-32

window 77-5

window layout 78-7

Deliberate-Attack, posture 23-4

Deliberate-Defense, posture 23-4 demonstration

creating 36-35

mode 78-9

Deploy Refueling Boom task 30-12 Deploy Sonobuoy task 30-17

Deploy Sonobuoys Along Route task 30-17 deploying

embedded entity 30-14

with task 30-16

sonobuoy 30-17 depth

bits 5-3

buffer 6-14

focal 49-23

moving to 27-15

ocean 55-27

sonar 34-40

depth charge 28-4, 28-9


depth of field 49-23 configuring 49-25

enabling and disabling 49-23 descent rate 27-10

description parameter 70-4

spawn pattern 20-10 deselecting

object 17-7

simulation object 17-7

DESIGNATOR, attribute 57-26

designator 15-6

buoy 57-26

laser beam 9-15

destAddrString parameter B-7 destination address 5-8, 5-13, B-7 Destroy Bridge dialog box 31-22 Destroy Bridge task 31-22 Destroy Ditch dialog box 31-22 Destroy Ditch task 31-17, 31-22

Destroy Explosive dialog box 31-22 Destroy Explosive task 31-22

Destroy Fortification dialog box 31-23 Destroy Fortification task 31-23 Destroy Obstacle dialog box 31-23 Destroy Obstacle task 31-23

destroyed, setting simulation object to 34-14 Destroyed set data request 34-14 destroyedsymbol attribute 83-8

destroyFedExec parameter B-6 destroying

booby trap 31-22

bridge 31-22

ditch 31-22

federation execution B-6 fortification 31-23

obstacle 31-23

unexploded ordnance 31-22

destroy-script-id parameter 32-21 detaching, observer from object 50-5 Detect Entity condition 35-10 Detected CID level 9-13

detecting, targets 9-13

detecting target 72-6

detection table 9-13 detection types, sensor 71-9 detection-types parameter 72-6 determinant

coefficients 72-23

direct 72-21

determinant (continued) power 72-19

range-coefficients 72-20

range-list 72-20

determinant block 72-22

detonating, IED and car bomb 34-15 detonation

configuring power of 72-19 effects 42-8, 82-2

event

mapping sound effects to 47-4 sound effects 47-2

line 42-9

proximity 72-16

result, sound mapping 47-8 sound mapping 47-8

detonation controller 72-16

Detonation Fuse Type dialog box 34-15 Detonation Fuse Type set data request 34-15 detonation interaction 72-13

Detonation Sound Editor page 47-9

detonation-munition parameter 72-29

detonation-on-destroy parameter 72-29

detonationParams.mtl 72-15, 72-18, 72-21, 72-

23, 72-34, 72-36

detonation-power-entry 72-18

Device address 5-8, 5-13 deviceAddress parameter B-7 dialog box 27-12

27-12

Active Sonar Mode 34-5 Activity 34-6

Add Conditional Expression 35-6 Add Group of Entities 21-8

Add Model Definition 81-12

Add Terrain Patch 55-6, 63-3, 63-21

Aggregate As 66-3

Aiming 34-7

Air-to-Ground Attack 31-4

Allow Crossing 40-4

Altitude 34-8

Ammunition 34-8

Ammunition Pacing/Tracking 34-9

Animated Movement 27-3, 65-52

Appearance 34-10

Application Settings 7-22, 24-11

File Caching Settings page 6-11, 61-2, 61-6

Key Mapping Editor page 80-4, 80-9 Mouse Mappings page 49-14 Performance Options page 6-15, 6-17



Application Settings 7-22, 24-11 Script Options page 32-37

Session Options page 4-7, 7-10, 7-11, 7-12,

7-22, 7-41, 49-22

Spot Report Options page 9-3, 9-5, 9-6, 9-8,

9-9, 34-41

Armed 34-11

Arrowhead Style 40-4 Attack By Fire 31-5

Attack with Anti-Air Missile 31-5 Attack with Anti-Ship Missile 31-5 Attack with Land-Attack Missile 31-6 Attack with Torpedo 31-6

Audio Settings 47-2, 47-3, 47-5, 47-6, 47-7,

47-9

Auto Launch 34-13

Ballistic Missiles 65-48, 65-52

Biological Attack 31-7

Bomb Location 31-8

Breach Obstacles 31-9

capabilities 34-11

Change Hostility 9-12 Change MOPP Level 31-10 Change Posture 31-11

Chemical Attack 31-11

Collision Avoidance Types 34-12 Color 40-4

Concealed 34-13

conditional statement 36-11, 36-23

configuring 79-3

Connection Information 4-31

Construct Abatis 31-12

Construct Anti-Tank Ditch 31-13 Construct Barbed Wire 31-14 Construct Barricade 31-14

Construct Berm 31-15 Construct Booby Trap 31-15 Construct Bridge 31-16 Construct Dry Gap 31-17 Construct Fortified Area 31-18 Construct Fortified Line 31-19 Construct Minefield 31-20 Construct Strong Point 31-21 Contamination 34-13

Create Anti-Tank Ditch 31-13 Create Barbed Wire 31-14 Create Barricade 31-14

Create Berm 31-15 Create Booby Trap 31-15


Create Bridge 31-16

Create Connection 70-10 Create Dry Gap 31-17 Create Fortified Area 31-18 Create Fortified Line 31-19 Create Indirect Fire 10-3

Create Intelligence Object 8-8

Create Minefield (ADAM-RAAM) 31-24 Create Minefield (Volcano) 31-20

Create Multiple Entities 21-7 Create New Component 70-8 Create New Entity 65-32

Create New Entity Type Model Mapping 82-4 Create Object 16-3

configuring 16-13

Create Pedestrians 21-3

Create Resource 70-11

Create Route 16-16 Create Scenario Event 8-3

Create Spawn Pattern 20-10, 20-14 Create Strong Point 31-21

Crowd Along Line 29-3 Crowd in Front of Entity 29-5 Current Speed 34-14

Delete Checkpoints 7-33

Destroy Bridge 31-22

Destroy Ditch 31-22

Destroy Explosive 31-22

Destroy Fortification 31-23

Destroy Obstacle 31-23 Detonation Fuse Type 34-15 DI-Guy Characteristics 34-16 DI-Guy Hand Item 34-16 Display Settings 4-21, A-2

Cockpit Display Settings page 51-5 Display Units Settings page 78-13

Entity Display Settings page 18-12, 18-13,

18-21, 18-22, 18-23, 18-35, 19-21,

19-22, 19-26, 26-6, 42-12, 42-19, 44-

6, 44-8, 48-12

Grid Lines Settings page 53-8 Indirect Fire Settings page 10-7

Interest Management Settings page 6-9 Intervisibility Settings page 46-6, 46-7, 46-9,

46-10, 46-11

Lighting Render Settings page 43-4, 43-5 Loader Settings page 61-11


dialog box (continued) Display Settings 4-21, A-2

Observer Settings page 18-26, 18-30, 18-31,

19-25, 19-26, 42-4, 42-5, 42-14, 43-

7, 44-3, 48-4, 48-5, 48-6, 48-9, 49-5,

49-24, 49-27, 49-30, 51-10, 53-7

Ocean Settings page 11-20, 43-9, 43-10, 43-

14, 44-4, 44-5, 55-18, 55-19

Radio Communications Settings page 42-21, 42-22, 42-23

Range Rings Settings tab 18-27

Render Settings page 6-7, 6-8, 6-18, 43-13,

49-25, 53-11, 61-9, 77-13

Sensor Settings page 45-4, 45-5

Shadow Settings page 43-20, 43-21 SpeedTree Settings page 83-23

Symbol Decoration Settings page 18-14, 18-

15

Tactical Graphics Display Settings page 37- 8, 37-9, 37-10, 39-17, 41-3

Terrain Profile Settings page 46-12 Track History Settings page 42-7

Unit Display Settings page 25-7, 25-10, 25-

11, 42-10, 42-17

Duplicate Model Definition 81-14 Edit Activities 67-16

Edit Behavior Sets 26-20, 26-21 Edit Spawn Pattern 20-15

Edit Trigger Condition 36-7 Embark On 19-9, 30-7

Embarked 34-17

Emitter 34-19

Engagement Results 34-19

Environment Conditions 11-13

Environment Settings 11-3, 11-4 Environmental Object Information 18-3 Equipment Pacing/Tracking 34-20 Execute Close Air Support 28-7 Experimental Features 11-21, 49-20, 49-21 Fast Rope Insertion 27-6

Fill Style 40-5

Fire Cruise Missile 28-10 Fixed Wing Land 27-7 Fixed Wing Takeoff 27-8 Flee From Entities 29-6 Follow Entity 27-11

Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant 34-20

dialog box (continued)

Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant Pacing/Tracking 34- 21

Force 34-21

Formation 34-22

Heading 34-23

Health 34-23

If/Else Expression 36-5

IFF 34-24

Improve Booby Trap 31-24 Improve Breach 31-25

Improve Bridge 31-25

Improve Ditch 31-25

Improve Fortification 31-26

Improve Obstacle 31-26

Indirect Fire 31-27

Information 18-3, 18-29

information, configuring 79-3

Initial Scenario Information 7-3, 7-11

Invulnerable 34-25

Jam Targets 34-25

Lase Autonomous 34-25

Laser Code 34-26

License Setup 2-6

Line Width 40-5 Load Batch File 7-39 Load Overlays 38-5

Location 34-26

locking 79-7

Manage Reactive Task 26-17 Manage Reactive Tasks 21-10 MOPP Level 34-27

Morale 34-27

Move Along Route 27-13 Move Into Formation 27-14 Move to Altitude 27-15 Move to Depth 27-15

Move to Location 27-16 Move to Waypoint 27-20

Munition Target Settings 10-3, 10-6, 10-8, 10-

10

New Scenario 7-35, 12-3

Notify Level 34-28

Nuclear Attack 31-29

Open Model Set 64-7, 64-16

Ordered Speed 34-29

osgEarth Profile 61-14

Overlay Layers 65-8

pages, configuring 79-2



Patrol Between 27-24

Patrol Route 27-23

Pattern Hold (Location) 27-24 Pattern Hold (Waypoint) 27-25 Pen Style 40-6

Percent Complete 34-29

Performance Options 6-15

configuring slider 6-16

Place IED 28-16

Plug-ins 4-32

Posture 34-30, 34-31

Preferred Targets 34-32 Protest Along Line 29-7 Protest Around Location 29-7 Radar Mode 34-33

Register Trigger 36-8

Resources 34-34

Resources Pacing/Tracking 34-34

Resupply Mode 34-35 Rotary Wing Land 27-26 Rules of Engagement 34-36 Sail Heading 27-27

Save Scenario 7-28

Scenario Event 8-11

Scenario Information 7-23

Scenario Snapshots 7-26, 7-31, 7-33, 7-34

Scenario Startup 4-6, 4-7 Sector of Responsibility 34-37

Sector Search Operation 28-20, 30-15 Send NBC Report 31-29

Send Obstacle Report 31-30 Set Scenario End Time 7-35 Set Sensor Signatures 8-9

Simulation Connections Configuration 4-32 Simulation Object Type Mappings 82-2 Sonar Depth 34-40

Spot Reports 34-41

Strafe Ground Target 28-22 Superior 34-42

Supplying 34-42

Surrendered 34-42 Synchronize Laser Code 34-43 Target 34-43

Terrain Settings

Add Props page 55-22, 63-9, 63-13 Earth Layers page 53-12

Edit Existing Props page 55-24, 55-25, 55-

26, 63-23

Extract Ocean page 55-15


Terrain Settings

Extract Props page 55-20, 63-21

Raster Maps page 55-7, 55-10, 63-5 SpeedTree Randomization page 83-25 Terrain Contents page 55-6, 55-12, 55-15,

55-16, 55-27, 56-3, 61-15, 63-3, 63-

21

Visible Surfaces page 53-3 Throw Grenade at Location 28-23 Throw Grenade at Target 28-24 Tracer Use 34-44

Turn to Heading 27-28 Unit State 34-44

User Task 30-18

Visual Model Editors 81-9 Wait Duration 30-11

Wait Elapsed 30-11

Wait Until Expression 36-6 Weapons Pacing/Tracking 34-45

Weather 11-15

While Expression 36-6 Window Layout Manager 78-4

diffuse, color 43-4 digging

anti-tank, ditch 31-13 DI-Guy

action table 68-4

adding new characters 68-3 animation

adding 68-4

testing for 35-11 appearance, testing for 35-11 character data file 5-10

choosing animation 68-5, 82-10 configuring B-3

animations and appearances 5-10 character and appearance 65-16, 68-3 use of B-6

instancing 6-19

integration with VR-Forces 29-5 license 1-17

model definition 81-12

motion file 68-4

performance 6-19

DI-Guy Animation task 29-5

DI-Guy Characteristics dialog box 34-16

DI-Guy Characteristics set data request 34-16 DI-Guy Hand Item dialog box 34-16

DI-Guy Hand Item set data request 34-16


DI-Guy Settings page 6-20 diGuyAnimationsFile parameter B-3 dipping, sonar 30-18

direct determinant 72-21

direct fire weapon, configuring 72-4 direct fire weapon system

damage-by-ammo-type, example 72-36

damage-by-power, example 72-31 direction

line, changing 39-16

Lua 33-18

tidal current 11-16, 11-18

wind 11-9 directory

appData 5-9

back-end data 5-10 back-end user data 5-12 data 2-4

installed 2-4

DirectX 61-10 DIS

command-line options 5-20 configuring B-7

encoding information in OpenFlight format 85-2

Enumeration Document 3-8

exercise ID 5-9, 5-13 heartbeat, threshold B-7 IPV6 5-13

port 5-9, 5-13

port number 5-20

self reflection 5-13

specifying broadcast modes 5-20 starting in 5-3

startup tutorial 4-9

timeout 5-10

WRM specification 85-1

DIS Enumeration Document 69-4 disable_if_checked 69-24

disable_if_multiple_selection 69-24

disabled-by-suppression parameter 26-34 disableParallelTick parameter B-3 disabling

advisory messages B-7 buoyancy 44-7

cockpit displays 51-3

creation of a simulation object type 65-7 decal effects 42-4

editing of overlay 38-3 entity labels 18-13

disabling (continued) environment 43-18 frame rate statistics B-4 intervisibility 46-10

joystick 19-20

joystick use 19-18

periodic checkpointing 7-32 radio communication lines 42-21 range rings 18-24, 18-26

reactive task 26-15

Scenario Startup dialog box 4-7 sensor contact line 42-13 shadows 43-19

speed scaling 49-28, 49-29

spot report 9-3

spot report for simulation object 34-41 squawk indicators 42-21

tactical smoke 42-17

terrain paging information 56-7 texture compression 61-6

track histories for all simulation objects 42-5 trailing effects 42-4

view constraint 19-4

wireframe mode 53-10 disaggregated state, unit 24-9 disaggregated unit 22-2 disaggregation

area 24-12, 37-2

automatic 24-12

manual 24-12

Disembark, command 19-11

disembark 19-11

all entities on parent 19-12 in echelon view 19-11

Disembark All task 30-3 Disembark task 30-3

Disembarked set data request 19-11, 34-17 disembarked status, testing for 35-11 disembarking

entities 19-7

entity 34-17

instantly 19-11 Disperse Crowd task 29-5 dispersing, crowd 29-5 display

dragging 49-15 field of view 77-14

loading configuration 5-3

navigating 49-3

perspective 77-14


display (continued) time, format 11-4

unit, changing 78-11

display engine 77-2

configuration 77-2

loading 77-5

saving 77-5

window, adding 77-2

Display Engine Configuration Editor Panel 48-6, 77-3, 77-4, 77-5, 77-6, 77-8

display mode, curvature of the earth 42-22 Display Models check box 65-25

Display Settings dialog box 4-21, A-2 Cockpit Display Settings page 51-5 Display Units Settings page 78-13

Entity Display Settings page 18-12, 18-13, 18-

21, 18-22, 18-23, 18-35, 19-21, 19-22,

19-26, 26-6, 42-12, 42-19, 44-6, 44-8,

48-12

Grid Lines Settings page 53-8

High Dynamic Range Settings page 43-16 Indirect Fire Settings page 10-7

Interest Management Settings page 6-9 Intervisibility Settings page 46-6, 46-7, 46-9,

46-10, 46-11

Lighting Render Settings page 43-4, 43-5 Loader Settings page 61-11

Observer Settings page 18-26, 18-30, 18-31,

19-25, 19-26, 42-4, 42-5, 42-14, 43-7,

44-3, 48-4, 48-5, 48-6, 48-9, 49-5, 49-

24, 49-27, 49-30, 51-10, 53-7

Ocean Settings page 11-20, 43-9, 43-10, 43-14,

44-4, 44-5, 55-18, 55-19

Radio Communications Settings page 42-21, 42-22, 42-23

Range Rings Settings tab 18-27

Render Settings page 6-7, 6-8, 6-18, 43-13, 49-

25, 53-11, 61-9, 77-13

Sensor Settings page 45-4, 45-5

Shadow Settings page 43-20, 43-21 SpeedTree Settings page 83-23

Symbol Decoration Settings page 18-14, 18-15 Tactical Graphics Display Settings page 37-8,

37-9, 37-10, 39-17, 41-3

Terrain Profile Settings page 46-12 Track History Settings page 42-7

Unit Display Settings page 25-7, 25-10, 25-11,

42-10, 42-17

Display Settings Toolbar 18-15 Display Terrain parameter 7-6

Display Units Settings page 18-23, 37-10, 78-13 displaying

contour lines 53-9

entity information 18-9

feature data 53-13

full screen 78-9

grid line 53-7

height-above-terrain lines 18-23, 37-10 intervisibility

lines 46-10

object 46-7 label

2D 18-14

entity 18-11

laser designator 42-16

levels of aggregation in Echelon View 25-4 navigation areas 58-5

navigation data 58-11

objects 37-6, 37-8

other MAK 3D GUI viewers 48-12 panel 78-3

performance statistics 6-6

range rings 18-24

globally 18-26

per entity 18-26

raster maps 55-7

resources 18-29

scenario information 7-21 Scenario Startup dialog box 4-7 segment outlines 84-6

stealth models 48-12

tactical graphics 37-8, 39-19, 40-3 terrain profile, creating line 39-6 toolbars 78-3

track histories 42-5

trailing effects 42-3

transient intervisibility 46-6

vertex labels 37-9

view 49-31

disPort parameter B-7

distance, specifying unit 78-11 Distance To Attached, policy 77-10 Distributed Interactive Simulation 1-22

See also DIS

ditch

anti-tank, digging 31-13

building 31-17

destroying 31-22

improving 31-25


DLL 4-31

cockpit display 83-10

installing cockpit display, installing 83-11 plug-in, removing 4-35

specifying for plug-in 4-35 dockable panel 78-2

docking, panel 78-2 documentation, location of 2-4 DOF bead 85-7

domain, power 72-18 doNotUseConsole parameter B-3 door

cargo

closing 30-11

opening 30-13

closing 29-2

opening 29-6

dotted line 39-17

Douglas sea state 11-16, 11-18

drag and drop, plan statements 36-40 drag-and-drop, canceling 16-20 dragging

canceling move 16-20

object to new location 16-19 objects 34-26

simulation object 16-19

terrain 49-14

view 49-15 drainInput

configuring B-4 for DIS B-7 for HLA B-6

dr-allow-gui-overrides parameter 6-16

draw call, coloring 6-18 drawing, box 39-3 driver

OGR 57-9

osgEarth 57-6

simple 57-22

driving, on and off roads 26-22

Drop Naval Depth Charge at Location task 28-4 Drop Naval Depth Charge task 28-4

Drop Naval Mine task 28-5

Drop Naval Mines Along Route task 28-6 dropping, mine 28-5, 28-6

dropping bomb 28-18 dropping from exercise 3-7 dry gap, building 31-17 DTED

file 52-3

DTED (continued) loading 55-4

loading multiple 57-6

support for 55-4

DtSimComponentManager class 69-9

DtSimObjectNetInterface class 69-9

DtSimObjectStateRepository class 69-9

DtSimTaskManager class 69-9

DtVrfObject class 69-9

dtxc, file 83-21

duplicate, key mapping 80-8

Duplicate Model Definition dialog box 81-14 dust cloud 42-3

dynamic avoidance 3-16

dynamic feature 62-10

dynamic lighting 43-2, 43-6 dynamic linked library 4-31

Dynamic Near Clip Attached Policy, attribute 77- 10

dynamic ocean 1-14, 11-16 enabling and disabling 11-17 layer 55-13

wake and spray, disabling 44-6 wakes 83-14

dynamic terrain 5-3

damage, high fidelity 72-29

global dynamic terrain processor 7-7 dynamic terrain area 59-3

dynamic terrain damage 72-28

Dynamic Water Visibility Enabled, attribute 77- 16

Dynamic Water Visibility Maximum, attribute 77-16

dynamic-terrain-munition-damage controller 72-

28

dynamic-terrain-type parameter 72-29


E

-E command-line option 5-4

-e command-line option 60-4 earth file 1-18, 52-5, 57-3

adding mask 57-14

areal features 57-12 buoys and beacons 57-23 caching, offline 61-5

debugging 61-14

differential processing of attributes and elements 57-21

hiding layers 53-12


earth file (continued) including files in 57-5 loading DTED 57-6

template 61-5

template, earth file 57-5 Earth Layers page 53-12 echelon ID 15-3, 15-4, 15-6

assignment of 15-7

unit member 22-3

echelon level, ghosted icons by 25-7 Echelon View 17-2, 24-7, 24-8, 25-4

aggregated unit 24-9

disaggregated unit 24-9

disembarking 19-11

expanding and collapsing units 25-4 ghosted units 25-6

levels of aggregation 25-4

echelon-level parameter 69-25

ECW 52-4

Edit Activities dialog box 67-16

Edit Behavior Sets dialog box 26-20, 26-21

Edit Existing Props page 55-21, 55-24, 55-25, 55-

26, 63-23

Edit Spawn Pattern dialog box 20-15 Edit Trigger Condition dialog box 36-7 editing 11-15

assembly 67-12

attack parameters 67-22

batch file 7-37

channel attributes 77-7

control object 39-12

defense parameters 67-23 electronic warfare parameters 67-23 element definition 81-25

ellipse 39-16

embarkation ingress and egress points 73-6 entity model 65-3

environment condition 11-7

equipment parameters 67-24

fill style 39-17

force hostility 9-10

formation 66-8

frustum 77-14

icon, 2D 83-2

indirect fire event 10-6 intervisibility object 46-8

key maps 80-3, 80-4

line 39-17

Lua scripts 32-38

model, visual 65-19

editing (continued)

model definition 81-9, 81-15

model mapping 82-5

movement system properties 67-20 navigation area 58-4

object

location, heading, altitude 19-5 scene 39-13

object map file 12-9 object parameters 65-3

observer mode 48-5

overlay and overlay object 38-3 parameter 65-12, 70-4

model definition 81-17

schema 81-8

personnel parameters 67-24

plan 36-3

file 12-8

statements 36-9

plans 36-3

posture, transition time 67-21 scenario description 7-23

scenario file 12-3

scripted task 32-30

sensor 71-4

sensor parameters 67-21

sensor signature 71-5

simulation object 64-3

simulation objects 19-5

spawn pattern 20-15

supplies parameters 67-24

system 65-31

properties 65-31

tactical graphic 39-12

property 65-55

visual model 65-56

unit 66-4

unit subordinate 66-7

vertex 39-14

visual definition 81-27

parameter 81-29

weather zone, environment 11-15 window attributes 77-6

effect

fire and detonation 42-8 lighting 1-15, 61-7

mapping 82-2

model 80-5

ocean 11-16

trailing 42-3


egress point 65-34, 73-6

configuring 65-36

egress-points parameter 73-6

electromagnetic emissions 34-18, 42-18

segment angle 84-5

sensing 23-18 electronic

emission, sensing 23-16

warfare 23-16, 23-17, 23-18

electronic warfare 23-16

electronic warfare parameter, editing 67-23 elem file 81-35

element

earth file, differential processing 57-21 informationitem 79-4

informationpagecollection 79-3

mainmenu 79-2

mainmenuconfiguration 79-2

mask 57-14

menuitem 79-5

model 57-8, 57-22, 83-24

option 57-21

pagecollection 79-3

pagecollections 79-3

parent 81-27

rightclickmenu 79-5

toolbar 79-6

toolbarrow 79-6

element definition 81-21

adding visual definition 81-26 common buttons 78-9

creating 81-24

deleting 81-32

editing 81-25

exporting 65-27, 81-35

exporting hierarchy and leaves 81-36 exporting to elem file 81-35

filtering list in Simulation Object Type Mappings dialog box 82-7

importing 65-26, 81-33, 81-34

pruning 65-26

saving 81-32

simulation object 81-21

spot report, regenerating 65-21 element_type 69-24

elevation

coloring terrain by 53-4 data 52-3

intervisibility point, configuring 46-9 Elevation Color page 53-4, 53-5, 53-6

ellipse

extruded 39-4

rotating 39-16

undoing and redoing rotation 39-16 ellipsoid, reference B-3, B-5

Embark On, command 19-9 Embark On dialog box 19-9, 30-7

Embark task 19-8, 30-4 embarkation

automatic 19-10

condition 35-11

configuring 65-34

slot exclusions 65-40

editing ingress and egress points 73-6 egress point 65-36

embedded entity alternative 19-12 immediate 19-8

ingress point 65-36

instant 19-10

occupancy-director-controller 73-6

slot 73-6

configuring 65-36, 65-38

Embarkation View 17-2, 19-7, 19-8, 19-11 embarking objects in 19-10

embarkation-slot-entry parameter 73-6

embarkation-slots parameter 73-6 Embarked dialog box 34-17 embarked object, information 18-4

Embarked set data request 19-9, 34-17 embarking

entities 19-4, 19-7

in Embarkation View 19-10 instantly 19-9

embedded entity 19-12, 28-20, 30-15 assigning tasks to 19-15 configuring 19-13

deploying 30-14 deploying with task 30-16 recovering 30-14

restoring parent 19-15 Simulation Object Editor 19-13 system 19-13

embedded window 77-2

EM-Emission update message 84-3 emission sensor 23-18

emissions-sensor system 23-18

emitter 34-33

beam 9-17, 34-18

component 34-18

configuring 74-2


emitter (continued) ID 34-19

information 18-4

setting 34-18

systems 42-18

Emitter dialog box 34-19 Emitter Power 84-3

Emitter set data request 31-4, 31-21, 34-18 emitter volume

color 84-2

configuring 84-2

outlines 84-6

pulse rate 84-2

radius 84-3

segment angle 84-5

segment size 84-4

enable_if_checked 69-24 enableDebugDrawer parameter B-3 Enable/Disable Spot Reports tab 9-3 enableLogFileTimestamps parameter B-3 enableNavigationLabDebugging parameter B-3 enabling

advisory messages B-7 buoyancy 44-7

cockpit displays 51-3

creation of a simulation object type 65-7 decal effects 42-4

editing of overlay 38-3 entity labels 18-13

external communication model 13-3 frame rate statistics B-4 intervisibility 46-10

joystick use 19-18

marine effects 11-17

periodic snapshot 7-34

radio communication lines 42-21 range rings 18-24, 18-26

reactive task 26-14

Scenario Startup dialog box 4-7 sensor contact line 42-13, 42-14

shadows 43-19

sound effects 47-2

speed scaling 49-28, 49-29

spot report 9-3

simulation object 34-41

squawk indicator 42-21

tactical smoke 42-17

terrain paging information 56-7 texture compression 61-6

enabling (continued)

time management 4-18

in back-end 4-19, 5-19

track histories for all simulation objects 42-5 trailing effects 42-4

wireframe mode 53-10 ending

scenario 7-27

scenario event 8-12

engagement, information 18-7 Engagement Results dialog box 34-19 Engagement Results set data request 34-19 engagement rules 34-36

Engineering Object Breached condition 35-10 Engineering Object Information page 23-12 entitiy, ways to add to scenario 7-16

entity

See also simulation object adding to, unit 24-7

adding to Props Palette 16-26, 81-10 aggregate-level

creating 67-3

parameters 67-17

aircraft, attacking with gun 28-3 altitude

displaying 18-23

testing 35-10

animation 27-3

appearance 85-2

attaching observer to 50-2, 50-7

avoiding obstacles, features, and collisions 19- 16

body frame coordinate system 49-7 bounding volume 18-30, 18-31

category, changing 65-3 centering observer on 49-26 clamping to ground 19-20

component, attaching to remote 76-2 components 69-13

configuring emitter 74-2

obstruction avoidance 73-4

console message 18-31 controlling by keyboard 19-20 controlling with joystick 19-18 copying 16-21

count 18-36

creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,

19-3

from existing 65-33


entity (continued)

creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,

19-3

in Simulation Object Editor 65-32 creating group of 21-5

creating in plan 36-33 deleting 19-5

from simulation model set 65-34 deleting in plan 36-33 disembarking 19-7, 34-17

all 19-12

display settings 5-4

dragging 16-19

editing 19-5, 64-3

element definition 81-21 embarkation

configuring 65-34

testing 35-11

embarking 19-4, 19-7

embedded 19-12 enumeration

in condition 36-22

in plan 36-24

extents, zooming on scenario load 49-22 filtering 6-8, 6-9

attachment list 50-5

fixed-wing 26-23

route following 26-27 following

entity 27-11

route 27-13

generating navigation data 58-9 ghosted 25-6

ground, road driving 26-22 ground clamping 19-22

heading, setting 16-17 icon

adding new image 83-9 changing size 18-21

image, adding 65-24

inset view 51-2

instrument panel, configuring 51-7 intervisibility 46-4

label 18-14

2D 18-11, 18-14

3D 18-9

color 18-9

enabling and disabling 18-13 pinning to display 18-13

level body frame coordinate system 49-7

entity (continued)

mapping sound effects to 47-4 messages, viewing 18-33

model 64-5, 80-5

adding visual 65-24

editing 65-3

editing visual 65-19

movement, scripted 65-47

moving 16-19 moving to

altitude 27-15

location 27-16

object or entity 27-20 name 18-9, 18-10

changing 19-5

pasting 16-23

notification level, object console 18-32 object geometry 65-14

organization 15-6

pasting, control object 16-22, 16-23

patrolling between 27-24

patrolling route 27-23

placing 16-11

new 19-3

on entity 19-4

platform, updating 64-19

primary 50-10, 50-13

properties, specifying at creation 16-13 random creation of 16-25

range ring 18-26 resource

at creation 19-4

monitoring 18-29 routes for aircraft 39-10

saving console messages 18-35 scaling, 3D model 19-23 secondary 50-10, 50-13 setting

collision avoidance types 34-12 target 34-43

shadows 43-19

sound effects 47-2

spawned 20-2

spawning, maximum simultaneous 20-11 specifying for multiple entity creation 21-8 storing list of 12-10

surface

buoyancy 44-7

configuring wake 83-14 symbol, changing color 64-23


entity (continued) systems 65-28

task, visualizing 42-12

tick rate 6-13

trailing effects 42-3

type, enumeration 18-10, 82-4

unit 24-2

velocity, publishing B-4 VR-Forces 3-9

wake, enabling and disabling 44-6 zooming to extents 49-22

Entity Altitude condition 35-10

Entity Behavior Options page 24-6, 24-11

Entity Definition Editor page 83-2, 83-15, 84-7 Entity Destroyed condition 35-10

Entity Di-Guy Animation Check condition 35-11 Entity Di-Guy Appearance Check condition 35-

11

Entity Display Settings page 18-12, 18-13, 18-21,

18-22, 18-23, 18-35, 19-21, 19-22, 19-

26, 26-6, 42-12, 42-19, 44-6, 44-8, 48-

12

Entity Editor. See Simulation Object Editor Entity Embarked condition 35-11

entity enumeration, changing 65-4 entity file, importing 64-18

Entity Has Target condition 35-11

Entity Image Symbol, visual definition 83-2, 83-4, 83-9

Entity In Area, condition 35-12 Entity In Area condition 39-4 Entity Left of Line condition 35-12 Entity List, filtering 17-6

Entity Mapping Settings page 82-4, 82-5, 82-7

entity plan 35-2

Entity Resource Manager 72-8

Entity Sound Editor page 47-5, 47-6, 47-7 entity state repository 72-7

entity type, changing 65-4

Entity Under Fire condition 35-12 Entity View 17-2

entity-level, modeling 15-10

entity-level modeling 21-1

EntityLevel.sms 15-11

entity-range parameter 72-9

entity-type parameter 72-9

entrance, embarkation 65-36 entry point, scripted task 33-7

entVrfDataTimeThreshold parameter B-3

enumeration 69-4, 82-4

entity, changing 65-4

for condition patterns 36-24 in condition 36-22

object type C-9

published and matching 69-6 environment

disabling 43-18

global 7-7

loading configuration 5-4

weather zone 11-15

editing 11-15

environment condition 11-5

adding 11-7

deleting 11-8

editing 11-7

marine, setting 11-17

Environment Conditions dialog box 11-13 Environment Conditions Settings page 83-17 Environment Settings dialog box 11-3, 11-4 Environment Settings Toolbar 11-4 Environment Settings toolbar 11-3, 11-4 environment variable

MAK_GEOID_GRID 55-4 MAK_VRF_ENABLE_DEBUG_DRAWER

56-8, 56-9

MAKLMGRD_LICENSE_FILE 2-7

OpenSceneGraph, anaglyphic stereo 77-21 OSG_CURL_PROXY 56-5

OSG_CURL_PROXYPORT 56-5

OSG_ICO 6-12

OSGEARTH_CACHE_PATH 61-3

OSGEARTH_CURL_PROXYAUTH 56-5

RTI_CONFIG 2-9

VRFSIM_OSGEARTH_CACHE_PATH 61-

3

Environmental Object Information dialog box 18- 3

Environmentals List, filtering 17-6 Environmentals View 17-2

ephemeris 7-7

model 11-2 equipment

pacing and tracking 34-20 unit 67-5, 67-8

Equipment Pacing/Tracking dialog box 34-20 Equipment Pacing/Tracking set data request 34-

20

equipment parameter, editing 67-24 equivalent task 32-23


escaping

plan 36-42

task assignment 26-7

event 15-9

linked, adding 8-6

list, numbering 8-13

scenario 8-2

Event window 8-10, 8-12

EW-Comms-Degradation-Percentage 23-16

EW-Comms-Dependence 23-16

EW-Defense-Strength 23-16

exaggerated reality 48-10 exaggerating, 3D models 19-23 exclusion, slot 65-40

execName parameter B-6

exectool, module 33-6

executable, installation locations 2-4 Execute Close Air Support dialog box 28-7 Execute Close Air Support task 28-7 execution name, HLA, specifying 5-17 exercise

clock 3-10

starting 7-24 exercise ID B-7

DIS 5-9, 5-13

exerciseId parameter B-7

exercise-start-time parameter 12-6

exit, embarkation 65-36 exiting

application 4-24

full screen window 78-9 plan 36-42

scenario 7-27

simulation engine 4-24

expanded label 18-9 pinning to display 18-13

expanding

unit 25-2, 25-3

all 25-3

Experimental Features dialog box 11-21, 49-20,

49-21

Explode Charge at Depth task 28-9 explosion 42-9

explosive device, arming 34-11 explosive device system 72-16 explosive power 72-15 explosive power domain 72-18 exporting

element definition 81-35

element definition to elem file 81-35

exporting (continued) element definitions 65-27

hierarchy 81-35

model definition 81-20

model definitions 65-27 object type mappings 65-27 overlays to shapefiles 38-6 scripted task 32-32

settings 4-21

visual models 65-27

extended label 18-17, 37-3

adding 18-18

deleting 18-19

index, changing 18-19

extended name 32-12 extent, zooming to 49-22

external communication model 15-7, 74-4

configuring 13-3

enabling 13-3

external communications effects server, config- uring VR-Forces for 1-17, 13-2

external reference 83-26 external script, editing 32-38 Extract Ocean page 55-15 Extract Props page 55-20, 63-21 extracting

prop 63-20

from terrain 52-4

from terrain patch 55-20 water texture 55-15

extras file 12-5 extruded

building 57-13

tactical graphic 39-4

extruded area 35-12

extruded geometry 52-5 eyepoint. See observer


F

-F command-line option 5-4, 5-14

-f command-line option 5-7, 5-12, 5-18, 60-4 face front culling 44-8

factory

window layout, restoring 78-7 factory settings, restoring 4-21 fan, intervisibility 46-4

far clipping plane 77-9 FASCAM task 31-24

Fast Rope Insertion dialog box 27-6


Fast Rope Insertion task 27-6 favorite 16-8

adding or removing from list 16-27 joystick configuration 75-14

observer view 49-32 Favorites, clearing list 65-9 favorites.mst 16-27

FDD file 2-9

feature 1-13

areal 57-12

attribute 62-4

avoiding 19-16, 73-4

configuration file 62-6 configuring avoidance of 73-5 coordinate 53-16

data

buoys and beacons 57-23 configuring 62-2

configuring in front-end and back-end 55-11 displaying 53-13

extracting from GDB 62-7 layer 62-7

ocean 55-27

processing 57-7

dynamic 62-10 extracting as prop 55-20 geometry 52-5

layer, adding 52-4

query 62-6

querying 62-3

soil type 53-16

SwitchStateMapper 83-20

UvAtlasMapper 83-20 vector, list of 53-14

feature layer 57-23

adding 55-11

adding prop from 55-22 name, specifying 62-2

Feature Settings page 53-15 featureconfig.txt

mapping, features 55-11

featureconfig.txt 73-5

featureDataBroker 57-7

FeatureSet class 33-3

FED file 2-9

name 5-7, 5-12, B-6

specifying 5-19 federate

name 5-8, 5-12, B-6

time managed 4-17

federateName parameter B-6 federateType parameter B-6 federation execution

destroying B-6 name B-6

specifying name 5-17

federation time 4-18

fedFileName parameter B-6

Feet Above Ground Level 83-12 Feet Above Mean Sea Level 83-12 FeetAGL updater 83-12

FeetMSL updater 83-12

FeetPerMinute updater 83-12

field of view 49-18, 49-19, 77-14, 77-15, 84-3

changing 77-14 file

ammo select 72-33

batch 7-36, 7-37

cache, clearing 61-6

caching 61-2

compressed 83-27

damage 72-17, 72-21, 72-35, 72-37

dtxc 83-21

FED 2-9, 5-19

formation 73-3

geometry 83-19

hit 72-35

hostility relationships 12-10

installed 2-4

log 4-38, B-3 MTL A-3

object map 12-9

OPE 72-3

order of battle 12-10

physicalWorldParams.mtl 71-9

plan 12-8

platform 69-16

RID 2-9, 5-17

rid.mtl 5-17

scenario 6-1, 12-2, 12-3, 12-7

scenario extras 20-9

scnx 6-1, 12-2

simulation model set 64-5 system definition 72-3

transporter 5-4

vrfGui.log 4-38

vrfSim.log 4-38 vrfSim.mtl B-2 vrfSimSettings.xml 6-15

File Caching Settings page 6-11, 61-2, 61-6


Filename parameter 83-11 filename_shp_map.txt configuration file 55-11 fill style 39-17

Fill Style dialog box 40-5

Fill Style set data request 40-5 filtering

earth file layers 53-12 element definition list 82-7 function list 80-9

model definition list 81-15 object attachment list 50-5 object lists 17-6

scripted task list 32-31 simulation object list 26-10 simulation objects

by observer altitude 6-9 in scene 6-8

finite state machine 33-6 fire

effects 42-8 event

mapping sound effects to 47-4 sound effects 47-2

indirect 10-2

line 42-9

suppressive 26-32, 28-17

at location 26-32

at point, line, or area 26-32, 28-17 target 28-9

Fire at Target task 28-9

Fire Cruise Missile dialog box 28-10 Fire Cruise Missile task 28-10

fire interaction 72-11, 72-13 Fire Sound Editor page 47-9 Fire-for-Effect task 28-11

firepower-kill parameter 72-26

fire-when-fired-upon 34-36 firing

at target 28-9

ballistic missile 10-8

cruise missile 28-10

effects 82-2

target at 9-13

spot report 9-15

Fixed Near Clip attribute 77-10

Fixed Near Clip When Attached, attribute 77-10 fixed weapon system, configuring 72-16

Fixed Wing Land dialog box 27-7 Fixed Wing Land task 26-29, 27-7 Fixed Wing Takeoff dialog box 27-8

Fixed Wing Takeoff task 26-28, 27-8

fixed-frame 4-18

fixed-frame best-effort 3-11, 12-6

fixed-frame keyword 12-6

fixed-frame-run-to-complete 3-11, 4-18

fixed-frame-run-to-complete keyword 12-6 fixed-wing

altitude 27-10

holding pattern 27-24, 27-25 landing at airport 27-12 strafing target 28-21

fixed-wing entity altitude 27-8

attacking with gun 28-3 circling a point 27-23 counter measures 28-13

creating 26-23

creating routes for 39-10 dropping bombs 28-18 follow entity behavior 27-11 heading 27-9, 27-10

landing 26-29, 27-7

route following 26-27

routes for 39-10 setting

altitude 26-25

IFF transponder 34-24

speed 34-29

takeoff 26-28

takeoff and landing 26-26 taking off 27-8

terrain following 26-26 writing plans for 35-19

fixed-wing-entity-param parameter 69-12, C-8

fixed-wing-entity-state-repository 69-12 flag, movement in wind 83-18

flaming effects 42-8, 82-2

flare 28-13

launching 9-19

flat earth, coordinate system 49-7 Flee From Entities dialog box 29-6 Flee From Entities task 29-6 FLEXlm 2-5

flight plan, generating air traffic from 27-12 flipping, DDS textures 55-6, 83-21

FLIR 45-2

floating, panel 78-2

FLT file 52-3, 80-5

Fly Altitude task 27-8

Fly Heading and Altitude task 27-10


Fly Heading task 27-9 flying

altitude to 27-8, 27-10

heading to 27-9, 27-10

focal depth 49-23

focal range 49-23

focus, scene 49-23

fog 11-5

denseness of 11-10 height and color 11-11

fog of war 5-4 fog-of-war 9-2

same side 9-7 folder

adding scripted task to 32-32 removing scripted task from 32-32 scripted task 32-31

adding 32-31

deleting 32-32

renaming 32-31

follow entity, fixed-wing entity behavior 27-11 Follow Entity dialog box 27-11

Follow Entity task 27-11 in plan 35-18

Follow mode 49-8, 50-7, 50-8 Follow Route task 27-13 following

paths 3-15

route 27-13

simulation objects 27-11

FOM 2-8

module 5-8, 5-12 FOM Mapper

configuring B-6 initialization data 5-7, 5-12 initialization string B-6 library name 5-7, 5-12 specifying at startup 5-18

fomMapperInitData parameter B-6

fomMapperLib parameter B-6 food 23-13

pacing and tracking 34-21 setting 34-20

Food, Water, Fuel, Oil, and Lubricant Pacing/Tracking set data request 34-21

Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant dialog box 34-20

Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant Pacing/Tracking dialog box 34-21

Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant set data request 34- 20

footprint 42-3

affect of posture 23-5 sensor 23-8

unit 23-4

force 15-6, 18-10

adding 64-22

Behavior Set, assigning to 26-21 color

2D icon 18-15

changing 64-23

editing 64-23 hostility

changing 64-23 changing in plan 9-12 matrix 9-10

name, changing 64-23

removing 64-24

setting at runtime 34-21 Force dialog box 34-21 Force set data request 34-21

tactical graphic 40-5

forceHostilty.mtl 9-10 forceParameterDbReload parameter B-3 format

OpenFlight 85-2

time display 11-4

formation 22-4

adding 66-9

bounding box 66-11

closing 22-5

configuring 73-2

copying 66-12

default 66-10

editing 66-8

expanding and collapsing in Formation Editor 66-10

file 73-3 layout

automatic 66-13

manual 66-13

moving to 27-14

removing 66-10

renaming 66-10

setting 34-22

in plan 35-18 snap to grid 66-14 supported 34-22


formation (continued) user-defined 73-4

Formation dialog box 34-22

Formation Editor 66-9, 66-10, 66-12, 66-13 Formation set data request 34-22

in plan 35-18 fortification

breaching 31-9

destroying 31-23

improving 31-26

fortified area, constructing 31-18 fortified line, constructing 31-19 forward arrow 65-46, 66-7 frame, length of 12-6

Frame Mode parameter 7-7 frame rate 5-12, 6-4, 6-17, 6-19

exercise clock 3-11

mode, specifying 12-6

setting 5-4 statistics

enabling and disabling B-4 log file B-3

Frame Rate Monitor panel 6-5 Frame Time parameter 7-7 frame-mode parameter 4-19, 12-6

time management 4-18 framentation power domain 72-18 frameRateStatisticsLogFile parameter B-3 frame-time parameter 12-6

free-fly mode 50-7

freehand line 39-2

sampling rate 39-2 frequency

color of 84-2

radio communication line 42-23 sampling for terrain profile 54-3

front-end 3-2

coordinating multiple 3-6

feature representation 52-5 joining session at startup 4-16 multiple 3-2

process ID 5-9

selecting database 7-3

sending messages 3-3

starting 4-3

frustum 77-7, 77-19

editing 77-14

fsm, module 33-6

fuel 23-13, 34-11

pacing and tracking 34-21

fuel (continued) setting 34-20

specifying amount 34-34

status 18-7

Full Color Mode 45-5

Full Knowledge CID level 9-13 full screen 5-7

mode 5-4

window 77-2, 78-9 function

list, filtering 80-9

movement 80-2

profiler 6-8

setCheckpointMode 33-14


G

-G command-line option 5-4, 5-16

-g command-line option 60-5 gain 45-2

changing 49-30

sensor effects 45-4

game pad 19-18

Gameware Navigation Lab 58-11 gamewareMemorySize parameter B-3 gasoline 23-13

GDAL 62-7

GDB, extracting feature data 62-7 GDB terrain 52-3

configuring soil type 53-2 shapefile 52-4, 55-11

Generate Air Traffic From Flight Plans task 27-12 generating

air traffic from flight plan 27-12 navigation data 58-5, 58-6

entity for 58-9

traffic 20-2 geocentric

converting to geodetic B-3, B-5 coordinate system 49-7, 52-6

vector 33-20

terrain 52-6, 56-2

geodetic, converting from geocentric B-3, B-5 geographic DDM 6-9

geoid grid file 55-4 geometric, objects 33-18

geometry 83-26

extruded 52-5

file 83-19

object, adding to entity 65-14


geometry (continued) sharing 6-11

Geometry Grid Dataset 60-3, 60-7

GeoTIFF 52-4

image 55-9

GGDS 60-7

ghosted

icon, by echelon level 25-7 unit 25-6

GIF 52-4

GL Studio 1-19, 51-3, 83-10

instrument panel 51-6, 51-7

license 1-20 global

environment 7-7

weather 7-7 global command

adding to plan 36-30 Create 36-33

Delete Object 36-33, 36-34

Delete Self 36-34

Issue Plan 36-34

global dynamic terrain processor 7-7 global plan 11-2, 35-2

creating 36-26

file 6-1

global setting 4-24

God ray 43-12 graphic

adding to scenario event 8-5 buffer, depth and stencil 6-14 depth 5-3

fire and detonation 42-9 mode, wireframe 53-10

object, showing and hiding 37-6, 37-8

unit combat 42-10

graphical object 37-2 changing, line width 39-17 deleting 39-11

spot report 9-9 graphical user interface 3-2

configuring 79-2

gravity, aligning cultural feature 65-15 grenade, hand 28-23, 28-24

grid line

configuring 53-8

displaying 53-7

Grid Lines Settings page 53-8 grid spacing, changing 66-14 ground, attacking from air 31-4

ground clamping 19-20

configuring 19-22

cultural feature 65-15

Ground Clamping Cutoff Distance Scale 19-22 ground truth 9-2, 9-4

ground vehicle

configuring obstruction avoidance 73-4 road driving 26-22

ground-entity-state-repository 69-12 ground-vehicle-param parameter 69-12, C-8 ground-vehicle-param parameter 69-3

group

entities, adding 21-8

selection 17-7

simulation object 16-25

GUI 3-2

configuring 79-2

layout, saving 78-3

layout settings 5-5

localizing 2-10

locking 79-7 settings

file 6-1

scenario 12-2

Simulation Object Editor, layout settings 64-5

guidance-mode parameter 72-18

guidelines 83-26

creating models 83-26

GuiObserverViews parameter 12-6

GuiScenarioSettings parameter 12-6

Gui-Terrain-Database parameter 12-5

gumball 18-7 gun

aircraft, attacking aircraft with 28-3


H

-H command-line option 5-8, 5-9

-h command-line option 5-4, 5-10, 5-14, 60-5 Halt Movement task 31-24

hand grenade 28-23, 28-24

Hasty-Attack, posture 23-4

Hasty-Defense, posture 23-4 HAT, See height-above-terrain line hazard, area 23-8

Hazards/Obstacles Palette 11-14, 16-4, 16-5, 23-9

HDR 43-16

header file, objTypeEnums.h C-9 heading 18-10, 49-3

flying to 27-9, 27-10


heading (continued) indicator 16-17, 18-11

intervisibility line 46-11

object, changing 19-5, 39-13

observer 49-4

pasting 16-23 rotating icon to 18-22 setting 16-3, 34-23

manually 16-17

specifying measurement unit 78-11 turning to 27-28

Heading dialog box 34-23 Heading set data request 34-23 headlight 43-2, 43-6

Headlight updater 83-13

health 23-2, 23-3

restoring simulation object 34-35 Health dialog box 34-23

heartbeat

back-end, configuring B-5 DIS B-7

relationship to thresholds 6-15 varying B-7

heartbeatVariance parameter B-7

heavy lift system 27-25 height

fog 11-11

ocean 55-15, 55-16 height map

ocean

regenerating 55-19

resolution 55-17, 55-18

texture size 55-17, 55-18

height-above-terrain line 18-23, 37-6, 49-28

displaying 37-10 helicopter

fast rope insertion 27-6

rotor wash, high quality 44-5 terrain avoidance 26-31

help 5-10, 5-14

heuristic, path planning 3-14 hide_by_default 69-24 hiding

3D models 19-26

intervisibility lines 46-10

objects 37-6, 37-8

overlay objects 38-4

panel 78-3

simulation objects 9-2

symbol decorations 18-15

hiding (continued)

tactical graphics 39-19, 40-3

toolbar 78-3

vertex labels 37-9 hierarchy

displaying levels of aggregation 25-4 element definition 81-21

entity 15-6

exporting 81-35, 81-36

importing 81-33

hierarchy file, importing 81-33 high dynamic range 43-16

High Dynamic Range Settings page 43-11, 43-16 high fidelity damage area 72-29

high-explosive, resource 23-13

high-fidelity-damage-table 72-29

high-fidelity-terrain-damage-table block 72-29

hit file 72-4, 72-35 hit probability

file 69-26

table 72-9

HLA 6-8, 6-9

1516

troubleshooting 7-41

command-line options 5-17

federation execution name, specifying 5-17 parameters B-6

specifying federation execution 5-17 starting in 5-4, 5-5

startup tutorial 4-9

time management 4-17 holding pattern

fixed-wing 27-24, 27-25

rotary-wing 27-24, 27-25

horizontal navigation 80-2

host address 5-8, 5-9, B-6, B-7 hostAddressString parameter B-6, B-7 hostile-fire-only parameter 26-34 hostility

changing, plan in 9-12 matrix, force 9-10

hostility relationships file 6-1, 12-10 hostname, license server 2-6

HUD. See cockpit display

human

idling 29-2

sliding down rope 27-6

human-param parameter 69-12, C-8 humans, adding to crowd 29-3 human-state-repository 69-12


I

-I command-line option 5-5

-i command-line option 4-8, 5-8, 5-9, 5-10 icon

2525B 83-2

2D 16-9, 83-4

bitmap 83-4

changing 65-21

displaying label 18-14

editing 83-2

image 65-22

bitmap, adding new 83-9 borders 18-20

common 78-9

configuring 2D 83-2 heading, rotating to 18-22 image 83-4

adding new 83-9 level of nesting 25-6 location of 2-4

notification 18-35

scaling, 2D 18-21

Set menu 32-11

settings 4-21

simulation object 18-21

size, changing 18-21 spot report

changing 65-23

updating 65-21

tactical graphic 65-53

Task menu 32-11

toolbar, setting 79-7

triangle 18-35

warning 18-35

yellow 9-13 ID

application 5-8

echelon 15-4, 15-6

emitter 34-33

object 15-4

script 32-8, 32-11, 32-21, 33-15

session 4-3, 5-8, 5-9

site 5-11, B-5

task 33-15, 33-16

unique 15-3 identification

simulation object, UUID 15-3 Identification Friend from Foe 34-24 identifier, site and application 3-4

identifying, simulation objects 15-3 idling, human 29-2

IED 72-17

arming 34-11

detonating 34-15

placing 28-16

If block, creating 36-5 If statement 35-4, 35-6

building 36-11

If/Else Expression dialog box 36-5 IFF 34-24

information 18-4 IFF dialog box 34-24

IFF set data request 34-24 illumination 71-12

model 7-7, 11-4

setting 11-2 image

2D icon 65-22

adding 65-24, 83-9

attributes 55-8

compressing 83-27

display order 55-10

displaying 55-7

format, supported 52-4

GeoTIFF 55-9

icon 83-4

texture coordinate system 55-9 imagery, filtering 53-12

imagesymbolmap attribute 83-7, 83-9

immediate embarkation 19-8

impact-point range 72-19 importing

element definition 81-33, 81-34

element definitions 65-26

entity file 64-18

hierarchy 81-33

hierarchy file 81-33

leaf file 81-34

leaf files 81-33

model definition 81-19

model definitions 65-26

MSDL 7-14, 7-16, B-4

navigation area 58-10

navigation data 58-10 object type mappings 65-26 scenarios 7-12, 7-16

scripted task 32-32, 32-33

settings 4-21

shapefiles to overlay 38-7


importing (continued) visual models 65-26

Improve Booby Trap dialog box 31-24 Improve Booby Trap task 31-24 Improve Breach dialog box 31-25 Improve Breach task 31-25

Improve Bridge dialog box 31-25 Improve Bridge task 31-25 Improve Ditch dialog box 31-25 Improve Ditch task 31-17, 31-25

Improve Fortification dialog box 31-26 Improve Fortification task 31-26 Improve Obstacle dialog box 31-26 Improve Obstacle task 31-26

improve-script-id parameter 32-21

improving

anti-tank ditch 31-25

booby trap 31-24

breach 31-25

bridge 31-25

ditch 31-25

fortification 31-26

obstacle 31-26

strong point 31-26

improvised explosive device, placing 28-16 inactive, tactical graphic 39-19, 40-3 including XML files in earth files 57-5 increasing speed of navigation 49-28 incremental compiling 6-12

independent mode, tutorial 4-9

independent setting, global and observer 4-24 independent task 25-1, 26-3

index

extended label, changing 18-19 indicator 18-13

heading 18-11

squawk 42-20

indirect fire 10-2

activation 39-19

creating 10-3

editing 10-6

Indirect Fire dialog box 31-27 Indirect Fire page 10-3, 10-6 Indirect Fire Settings page 10-7 Indirect Fire task 31-27

indirect fire weapon system 72-14 indirect-fire-actuator 72-14

indirect-fire-controller 72-14

indirect-fire-weapon-controller 72-14

individual, plan 11-2

individual-lifeform-param parameter 69-12

individual-lifeform-state-repository 69-12 information

connection 4-31

entity label 18-9

multiple objects 18-9

object 18-3

scenario, displaying 7-21

Information dialog box 18-3, 18-29 centering observer from 49-26

information dialog box, configuring 79-3 information message B-4 informationitem, element 79-4

informationpagecollection, element 79-3

infrared 45-2

ingress point 65-34, 73-6

configuring 65-36

ingress-points parameter 73-6 inheritance, element definition 81-21

Initial Scenario Information dialog box 7-3, 7-11 Initial Unit State 24-6

initialization string, FOM Mapper B-6 initial-road-preference parameter 34-28 input

of data 69-13

port and port group 69-14 inserting, altitude point 53-5 inset view 51-2

installing, RTI 2-9

instancing 5-5

DI-Guy 6-19

instant embarkation 19-8

instrument panel 51-6

configuring 51-7

GL Studio 51-6, 51-7

instrumentPanelCategory parameter 51-7 Intel Collection Area 39-9 intelligence object 8-8

intensity, rain and snow 11-12 interaction 3-12

detonation 72-13

fire 72-11, 72-13

signal 42-20

interactive script 33-23

interest management 6-8, 6-9

configuring 6-9

Interest Management Settings page 6-9 interface

Lua 33-3

weapon 72-6


intermediate contour line 53-9 intersection, KD trees 5-5 intersector line, terrain 61-12 Intersector Settings page 61-12 interval

contour line 53-10

spawn 20-6, 20-8, 20-12

timeout 5-8

intervisibility 46-2

enabling and disabling 46-10 entity 46-3, 46-4

fan 46-3, 46-4

moving 46-8

grid 46-3

line 37-2

hiding 46-10

information 46-11 object

configuring 46-9

deleting 46-12

displaying 46-7

editing 46-8

transient and permanent 46-5

pinning object to simulation object 46-10 point-to-point 46-3

terrain profile 46-12 terrain profile line 54-6 types 46-3

Intervisibility Settings page 46-6, 46-7, 46-9, 46-

10, 46-11

invalid model definition 81-18 invert pattern 36-22

Invert Selection check box 36-23 inverting condition parameter 36-22 Invulnerable dialog box 34-25 Invulnerable set data request 34-25 IPV6 5-9, B-8

DIS 5-13

Issue Plan, command 36-34 itemname, attribute 79-2, 79-6

IVE 56-6


J

Jam Targets dialog box 34-25

Jam Targets set data request 34-25 jammer

activating 31-4

deactivating 31-21

jamming

communications 23-16

radar 23-16, 23-17

jamming-defense-factor parameter 23-17

jam-strength-factor parameter 23-18

jitter, camera 49-27 joining exercise, late 3-7 joystick 19-18

configuration creating 75-4

favorite 75-14

configuring 75-2

control, mapping 75-6

controller 75-2

disabling 19-20

keyboard contorl 19-20

Joystick button 75-6

Joystick Configuration page 75-4, 75-6, 75-7

JPEG 52-4

JPG 52-4

JRM Technologies 45-2

jumping 34-31

observer 49-16


K

KD tree 5-5

key map 80-2

creating 80-9

deleting 80-9

editing 80-4

key mapping 49-11

adding 80-5

binary 80-4

changing 80-7

combining 80-8

deleting 80-7

Key Mapping button 75-7

Key Mapping Editor 80-2, 80-3

adding mapping 80-5

binary mapping 80-4

changing mapping 80-7

deleting mapping 80-7 filtering function list 80-9

Key Mapping Editor page 80-4, 80-9 key value pair, reader writer 67-26 keyboard 80-2

attaching to objects from 50-3 changing speed 49-30


keyboard (continued) control 78-9

mapping 75-7

controlling entities 19-20

creating selection group from 17-9 entity control, configuring 75-2 inset views 51-2

mappings 49-6, 49-10, 80-3

movement functions 49-6

moving observer 49-10

navigation 80-2

key-names, location of configuration files 76-3 keyword

channel 77-7

largeCompass 49-5

smallCompass 49-5

tactical graphic property 65-55 KilometersPerHour updater 83-12 kinetic power domain 72-18 kneeling 34-31

KnotsPerHour updater 83-12


L

-L command-line option 5-5, 5-10, 7-18

-l command-line option 5-5, 60-5

label 15-3 2D

background 18-16

displaying 18-14

showing and hiding 18-15 entity 18-14

2D 18-11

3D 18-9

enabling and disabling 18-13 extended 37-3

object 15-5, 18-14, 37-3, 37-9

overlay 38-4

pinning to display 18-13 simulation object 15-5, 18-14

extended 18-17

spot report 9-9

tactical graphics 37-3, 37-9

Lambert Conformal Conic, coordinate system 49- 7

lamppost, prop type 55-26

Land at Airport Near Location task 27-12 land attack, missile 31-6

landing

fixed-wing entity 26-26, 26-29, 27-7

landing (continued)

rotary-wing entity 27-26 language

scripted task 32-25

specifying 5-4

for GUI 5-16

largeCompass, keyword 49-5

Lase Autonomous dialog box 34-25

Lase Autonomous set data request 9-16, 34-25 Lase Target task 9-16, 28-12

laser

autonomous 34-25

bomb 28-18

code 34-26

range 9-15

synchronizing between entities 9-16, 34-43

using 9-15

designator, displaying 42-16

targeting 28-12

Laser Code dialog box 34-26

Laser Code set data request 9-15, 9-16, 34-26 laser guided missile 72-13

laser-guided missile 72-13

lasing, autonomous 9-16

lasing controller 72-13

Last Clicked Location Panel 53-16

Last Clicked Object Panel, centering observer from 49-26

late joiner 3-7

lateral-clearance parameter 73-4

latitude 18-10, 33-18

Launch Anti-Submarine Missile (Vertical) task 28- 12

Launch Counter Measures, task 9-19 Launch Smoke task 28-13

Launcher, VR-Forces 4-3

launcher controller 72-13 launching

counter measures 9-19

torpedo 28-14 layer

earth file

debugging 61-14

hiding 53-12

feature 57-23

adding 52-4, 55-11 adding prop from 55-22

feature data 62-7

name 57-9

shapefile 57-9


layer (continued) ocean 55-13

adding 55-16 layout

default, clearing 78-6 formation

automatic 66-13

manual 66-13

GUI 5-5, 64-5

choosing 78-5

creating 78-4

default 78-5

deleting 78-7

renaming 78-7

restoring factory 78-7

reverting 78-6

saving 78-3

updating 78-6

LCC, coordinate system 49-7

leader-promotion-id parameter 73-3

leaf, exporting 81-36

leaf file, importing 81-34 leaf files, importing 81-33 length

intervisibility object 46-8 simulation object name 15-4 track history 42-6

LettersNumbers.ctxc 57-27

level, notification for messages 5-16 level observer 49-7

level-of-detail 49-18, 49-19, 83-22

See also LOD library, dynamic 4-31 license

3D models 1-21

DI-Guy 1-17

GL Studio 1-20

OpenSceneGraph 1-22

osgEarth 1-22

SilverLining 1-19

SpeedTree 1-21

License Manager 2-5 license server, hostname 2-6

License Setup dialog box 2-6 lifeform 35-12

appearance, random 65-17

configuring DI-Guy appearance and character 68-3

setting, posture 34-31

Lifeform Surrendered condition 35-12

lifetime

radio communication line 42-22

squawk indicator and communication line 42- 22

light

daylight control 43-7

navigation 57-29

point 43-7

source 43-7

light characteristic attribute 57-31

light_layer_list.csv 57-29 lighting

disabling 43-18

dynamic 43-2, 43-6

effects 1-15, 61-7

high dynamic range 43-16

Lighting Render Settings page 43-4, 43-5

limitation, terrain 55-4 limited munition attack 23-7 line

arrow, editing 39-17

changing width 39-17 creating

displaying terrain profile 39-6 opening terrain profile 54-3

direction, changing 39-16 dotted and dashed 39-17 editing 39-17

opening terrain profile 54-3 fire 42-9

fortified, constructing 31-19

freehand 39-2

height-above-terrain 18-23, 37-6

intervisibility 37-2

information 46-11

radio communication 42-20

sensor contact 42-15

style 39-17

supply 42-17

suppressive fire at 26-32, 28-17

task visualization 42-12

terrain profile 37-2, 54-6

for intervisibility 46-12

vertex, showing in terrain profile 54-3 Line Width dialog box 40-5

Line Width set data request 40-5 linear feature, list of 53-14

linear obstacle 37-2, 37-5

linear scaling 19-23


line-of-sight

See also intervisibility communication line 42-22

terrain profile 46-12 unit versus entity 23-8

linked event, adding 8-6 lisp C-2

list

Categories 65-9

clearing Categories, Used by Countries, and Favorites 65-9

props 55-24

spot report 9-9

Used By Countries 65-9 vector feature 53-14

list box, multiple 26-8

listing, components in OPD 69-16 LITCHR attribute 57-31

Little Pond terrain 53-19 load balancing 7-19

Load Batch File dialog box 7-39 Load Overlays dialog box 38-5

Load Scenario dialog box 7-17, 7-19

load-entry parameter 73-6

load-entry-point parameter 73-6 Loader Settings page 61-11 loading

cargo 27-26

database 52-7

display engine configuration 5-3, 77-5

DTED 55-4

entities on entities 19-7 entity display settings 5-4

environment configuration 5-4

MetaFlight 56-5

models 61-2

multiple DTED files 57-6 object type mapping 5-4

plug-ins 4-32, 4-33, 5-3, 5-5, 5-6, 5-10, 5-17

preventing 5-7

saved views 49-33

scenario 5-7, 5-10, 7-17

at startup 7-18

recently used 7-18

settings 4-21

tactical graphics 38-5

terrain 4-19, 61-2

from command line 5-7 paged 5-10

loadPluginIfVersionMismatch parameter B-4

local

object 3-9, 69-9

network interface 69-12

simulation object 3-9

Local Weather Zones page 11-13 locale, specifying 5-4

localization, specifying 5-4

localizing, GUI 2-10

local-objects parameter 69-9, C-4 localSettingsDesignator parameter B-6 location

compass 49-5

fixed-wing at creation 26-23 jumping to 49-16

moving to 27-16

new entity 19-3

object, changing 19-5, 39-13

observer 49-3

ordering entity to 27-16

ordering simulation object to 27-16 setting 16-3, 34-26

by dragging 16-19 suppressive fire at 26-32 window 77-6

Location dialog box 34-26 location image attribute 55-9 Location set data request 34-26 Location3D class 33-18

locking

GUI element 79-7

overlay 38-3

LOD 49-18, 49-19, 83-22, 83-26

ocean elevation 55-16 paged, scale factor 49-20 scale, setting 43-10 terrain, zooming in 49-21

LOD distance, buoyancy 44-7 log file 4-38, 5-11, B-3

frame rate statistics B-3 messages sent to 5-16

sending entity messages 18-35 specifying 5-5

vrfSim 5-11 logFrameRateStatistics parameter B-4 Logger

recording to 7-41

recording view control messages 36-35 Logger Control message 7-40

logger-files-path parameter 7-38

logical, operator 35-14


logistics 23-13

resupply, starting or stopping 34-42 resupply modes 34-35

longitude 18-10, 33-18 Lower Periscope task 30-12 Lua 32-3, 32-5

background process 33-30

classes 33-3

direction vector 33-18

interface 33-3

locations and vectors 33-18 method 33-3

module 33-6

object 33-3

location of 33-18

parameter 33-17

as table 33-15

require 33-6

script, extended name 32-12 table 33-15

tasks and subtasks 33-15 utility functions 33-6 vector

geocentric 33-20

offset 33-20

lua

global variables, saving 33-14

Lua API Documentation 33-3, 33-15

lubricant 23-13

setting 34-20

lubricants, pacing and tracking 34-21 LWO file 52-3


M

-m command-line option 60-5 magnification, performance 49-21

mainmenu, element 79-2

mainmenuconfiguration, element 79-2 MÄK Encrypted Data Format 60-7 MÄK RTI, configuring 2-9

MÄK Technologies LISP A-3 MAK_EARTH_FILE attribute 62-4 MAK_GEOID_GRID, environment variable 55-

4

MAK_LAYER attribute 62-4

MAK_SOURCE_FILE attribute 62-4 MAK_VRF_ENABLE_DEBUG_DRAWER,

environment variable 56-8, 56-9

making decisions 15-9

Makland terrain 53-19 MAKLMGRD_LICENSE_FILE, environment

variable 2-7

Manage Reactive Task dialog box 26-17 Manage Reactive Tasks dialog box 21-10 managing, plug-ins 4-31

manual

aggregation 24-11

aggregation and disaggregation 24-12 conventions lvii

location of 2-4 map

cube, recalculating 43-14

texture 1-15, 61-7

map datum, configuring B-6 Map Scale Toolbar 53-17 mapping

joystick controls 75-6

joystick keyboard controls 75-7 keyboard 49-11

keys 80-3 model

to object type 82-4

to remote observer 48-12 movement to keyboard 49-10 object type 82-4

shapefiles to features 55-11 soil types 61-13

sound effects 47-4 sound file to entity 47-5

marine

conditions, setting 11-17

effects, enabling and disabling 11-17 marker, system 65-31

Marker Labels, check box 65-31 Marker Labels check box 65-25 marker-scale attribute 83-24

marking, remote simulation object 35-19 marking text 18-10, 65-7

mask

adding to earth file 57-14 element 57-14

matching object type 69-6 material, ambient value 43-4 Max Sheaf Radius 31-27

max-detonation-distance-for-passing-rounds parameter

26-34

maxDrainInputReads parameter B-7 maxDrainInputTime parameter B-4 maximum sheaf parameter 67-12


max-range parameter 28-19

max-range-altitude parameter 28-19

max-slope parameter 26-28

max-speed parameter 34-29

max-thrust parameter 26-28 mcastTtl parameter B-7 MEDF 60-7

creating 83-27

file 52-3

medfTool 60-7

media, adding to scenario event 8-5 MEIF, creating 83-27

memory 6-4

improving use of 6-11 menu

configuring 79-2

context-sensitive 78-9

locking 79-7

popup 79-5

separator 79-2

Settings 4-21

Task 32-4

tearing off 78-8

menuitem, element 79-5

menuname, attribute 79-2 merging

model definition 81-19

scenarios 7-12

message 5-11

console 5-11

entity 18-31

saving 18-35 frequency of B-3

information and warning B-4 notification level 5-6

notification of 18-35

object, viewing 18-33

object console, sending 36-33 radio 30-7, 30-9

receiving 74-4

sending 74-4

between front-end and back-end 3-3 text 30-10

sent 15-9

session, configuring 4-16

setting levels 5-16

Start/Resume 7-41

state update 48-11

Stop/Freeze 7-41

time stamp ordered, TSO 4-18

message (continued) view control 49-34

warning icon 18-35

message-timeout parameter 13-3 metadata

in system definition file 69-17 script 32-5

metafile, texture skinning 83-19, 83-20

metaFileName parameter 83-19, 83-20, 83-21 MetaFlight

building efficient terrains 60-2 loading 56-5

processing 60-3

method, Lua 33-3

mftTool 60-4, 60-6

middle-click menu 78-9 migrating

object parameter database to new release 69-27 SMS 64-13, 64-14

MilesPerHour updater 83-12

Military Scenario Definition Language, importing 7-14

Military Symbol Icon, visual definition 83-2 MIL-STD 2525B color 19-26

unit 25-11

Mimic Location Track mode 50-10 Mimic mode 49-8, 50-7, 50-9 Mimic Track mode 50-10 mimModule parameter B-6 minDrainInputTime parameter B-6 mine

dropping 28-5, 28-6

naval, arming 28-3

sweeping for 28-23

minefield, creating 31-20 minimum lift speed 26-28 minimum tick period 6-13 minimum tick period variance 6-13 min-tick-period parameter 6-13

min-tick-period-variance parameter 6-13 mirror image attribute 55-8

missile 72-12

anti-air 31-5

anti-ship 31-5

anti-submarine 28-12

ballistic 10-8

firing 10-8

target event 10-10

cruise 28-10

land attack 31-6


missile (continued) laser guided 72-13

laser-guided 72-13

types 72-11

Missile Approach Warning condition 35-12 missile attack 23-7

missile controller 72-12, 72-13

missile launcher 72-11

laser guided 72-13

missile launcher system 72-11 Missile Target, page 10-8, 10-10 missile target event 10-10

missile-collision actuator 72-12, 72-13

missile-entity-state-repository 69-12

missile-maneuver actuator 72-12, 72-13

missile-param parameter 69-12, C-8

Mission Oriented Protective Posture. See MOPP mobility, modifier 23-9

mobility-kill parameter 72-26

mode

Absolute 50-7

batch 7-36

C and 5 in IFF 34-24

Follow 50-8

Mimic 50-9

Mimic Track 50-10

observer 48-2

Space Follow 50-11

specifying 5-20

speed scaling 49-29

Tether 50-12

Tether Track 50-13

Track 50-14

view 49-8, 50-7 model

3D 16-9, 80-5

changing 65-20

DI-Guy 29-5

exaggerating entity 19-23

hiding 19-26 adding

as prop 83-13

visual 65-24

aggregate-level, new 67-3

animation 85-11

calculating support point from 65-12 colorized, changing 65-20

communication 13-2

compressing 83-27

creating 83-26

model (continued) decal effects 42-4

definition, buoy 57-24

DI-Guy, choosing 68-5, 82-10 editing model mapping 82-5 element 57-7, 57-8, 83-24

entity 64-5

editing 64-3, 65-3

file caching 61-2

flipping DDS textures 83-21 illumination 11-4

instance, caching 6-11

instancing 5-5

layer, filtering 53-12 mapping

adding 82-4

common buttons 78-9

deleting 82-7

editing 82-5

to remote observer 48-12 name 18-10

object 64-5

physical 15-9

schema 81-9

set 48-11, 81-25

changing 48-11

showing 65-25

sharing resources 6-11

simulation 64-5

stealth 48-12

tactical graphic 65-56

texture 83-19

texture atlas 83-19

topological 3-12

trailing effects 42-4

types 80-5

vehicle 1-7 visual

editing 65-19

refreshing 65-27 model definition

adding 65-24, 65-25

buoy 57-23, 57-24

building from attributes 57-24 texture atlas 57-27

compass 49-5

copying 81-14

creating 81-9, 81-12

cockpit display 83-11

DefaultEllipsoidArc 84-2


model definition (continued) deleting 81-13

DI-Guy character 81-12

editing 81-15

exporting 65-27, 81-20 filtering list of 81-15 importing 65-26, 81-19

importing from command line 81-19 invalid 81-18

merging 81-19 parameter

adding 81-15

deleting 81-18

editing 81-17

prop, changing 55-26, 63-23

pruning 65-26

saving 81-20

schema 81-4

SpeedTree 81-12

tactical graphic texture 65-56 texture atlasing 83-19

wake 11-19

Model Definition Editor page 81-9, 81-12, 81-13,

81-14, 81-15, 81-17, 81-18, 81-20, 83-

9, 83-19, 83-21, 84-5, 84-6, 84-7

model element 57-22

model instancing 6-11

cache, clearing 6-11

model set 48-11

Model Specification for DIS Interoperability 85-2

modeldefinitionschema, attribute 83-6 modeling

aggregate-level 15-10, 21-1

entity-level 15-10, 21-1

modifier 23-3

combat engineering object 23-9 mobility 23-9

visibility 23-10

vulnerability 23-9

modifiers 67-17 modifying

control object 39-12

sensor signature 39-9 module

exectool 33-6

fsm 33-6

location of 33-6

Lua 33-6

monitor, multiple 77-17 monitoring, entity resources 18-29

MOPP level 23-8

changing 31-10

setting 34-27

MOPP Level dialog box 34-27 morale, setting 34-27

Morale dialog box 34-27 motion, file 68-4

mouse

changing speed 49-30

drag terrain 49-14

drag view 49-15 locking to object 16-18

moving observer 49-14, 49-15, 49-18

orbiting terrain 49-15, 49-18

teleporting observer 49-16

Mouse Mappings page 49-14, 49-18 Move Along Route dialog box 27-13 Move Along Route Retrograde task 31-28 Move Along Route task 27-13

Move Into Formation dialog box 27-14 Move Into Formation task 27-14

Move to Altitude dialog box 27-15 Move to Altitude task 27-15

Move to Depth dialog box 27-15 Move to Depth task 27-15

Move to Location (Plan Along Roads) task 26-22, 27-18

Move to Location dialog box 27-16 Move to Location Retrograde task 31-28 Move to Location task 27-16

in plan 27-17

Move to Waypoint (Plan Along Roads) task 27-21 Move to Waypoint dialog box 27-20

Move to Waypoint Retrograde task 31-28 Move to Waypoint task 26-22, 27-20 movement

DI-Guy 29-5

lifeform 34-31

model 65-28

specifying 65-30

retreat 31-28

scripted 27-3

speed, affect of posture 23-5 speed scaling 49-28

stopping 31-24

system 65-29, 69-17

task, affect of aggregation and disaggregation 24-10

unit 22-4, 23-6

restriction 62-9


movement file, configuring 65-51 movement parameter 67-19 movement system

properties, editing 67-20 moving

along a route 27-13 articulated parts 30-11

camera 49-13

in formation 35-18

intervisibility fan 46-8

object 16-19

objects 16-19, 34-26

between overlays 39-5

observer 49-3, 49-12

mouse with 49-14, 49-15, 49-18

options 49-12

to altitude 27-15

to location 27-16

to points or simulation objects 27-20 vertex 39-14

moving object parameter C-8

moving-object-param parameter 69-12, C-8 moving-object-param parameter type C-8 MSDL, importing 7-14, 7-16, B-4

MTD file 52-3 MTL file 52-3, A-3

vrfSim.mtl B-2

MTP file 52-3

multicast address, configuring B-7 multicast mode, specifying 5-20 multicast time-to-live 5-20, B-7 multichannel, configuring 77-17

MultiGen-Paradigm, OpenFlight format 85-2 multimedia, adding to scenario event 8-5 multiple

back-ends 3-2, 3-7, 12-9

front-ends 3-2

coordinating 3-6

object, information 18-9

parameter values 81-29 simulation model set 7-8 VR-Forces processes 3-2

multiple entity creation 21-5 specifying entity type 21-8

multiple list box 26-8

Multiple Object Information window 18-9 munition, display of path and detonation 42-9 munition block 72-18

Munition Target Settings dialog box 10-3, 10-6, 10-8, 10-10

munition-type parameter 72-8

munition-type parameter 72-37

mutually exclusive task 25-1, 26-5, 35-7

configuring 26-35

mutually-exclusive-task-groups parameter 26-35

muzzle flashes 42-8


N

-N command-line option 5-7, 5-8, 5-12

-n command-line option 5-6, 5-11, 5-16

name 15-3 changing

simulation object 65-7

tactical graphic 19-6

changing overlay 38-4

component 69-13

control object 37-2

default 16-11

displaying 18-11

entity 18-9, 18-10

extended 32-12

feature layer, specifying 62-2 FED file B-6

federate B-6

in condition 36-22, 36-23

layer 57-9

object 65-7

setting 16-3

short 65-7

simulation object 15-4, 18-9, 65-7

slot 30-7, 65-34

spawn pattern 20-10

trigger 35-8

named query 62-3

Naval Depth Charge Deployment, system 28-4 Naval Mine Deployment, system 28-5, 28-6 naval mine explosive device system 72-16 navigating

unit hierarchy 66-7

view 49-3 navigation

advanced 58-2

attached context 49-8 function, editing key map 80-4 key map 80-2

keyboard 80-2

light 57-29

streaming 57-29

options to 49-12


navigation (continued) speed scaling 49-28

navigation area

cancelling generation of navigation data 58-7 configuration file 58-10

creating 58-3

displaying 58-5

editing 58-4

reverting 58-5

generating navigation data for 58-6 importing 58-10

pedestrian path 21-9, 37-2

removing 58-5

status 58-7

Navigation Areas page 58-3 navigation data 3-12, 58-2

displaying 58-11

generating 58-5, 58-6

canceling 58-8

removing from queue 58-7 generating for entity 58-9 importing 58-10

profiles 58-6

using 58-8

Navigation Lab 58-11 debugging B-3

viewing simulation objects in 58-13 Navigation Preferences set data request 34-28 navigational aid light 57-31

navigation-preference parameter 34-28

NBC

area 23-7, 23-8

report 31-29

sending 31-29 near clipping plane 77-9

Near Far Clip Policy, attribute 77-10

net-interface-min-tick-period parameter 6-14, C-5, C- 7

net-interface-min-tick-period-variance parameter 6-14,

C-5, C-7

network

connecting to, automatically 5-3 vector 26-22

network interface C-5 hierarchy 69-12

network-interface parameter C-5, C-7

new

spawn pattern 20-10

terrain 55-3

window 4-13

New Scenario dialog box 7-35, 12-3

night vision 45-2

night-illumination parameter 71-13 no dialog box 5-15

node, switch 83-18, 83-20

noise 45-4

propulsion, RPM 9-18

non-VR-Forces, simulation object 35-19 normal map 1-15, 61-7

notification, icon 18-35 notification level 5-11, B-4

setting 5-16, 34-28

setting for entity console 18-32 specifying 5-6

Notify Level dialog box 34-28 Notify Level set data request 34-28

tactical graphics 40-5 notifyLevel parameter B-4 Nuclear Attack dialog box 31-29 Nuclear Attack task 31-29

nuclear contamination 23-7, 23-8, 31-29

numbering, events 8-13

number-of-runs parameter 7-38

NVG 45-2


O

-O command-line option 5-6 oberver, camera shake 49-27 OBJ 80-5

file 52-3 object

adding

resources in OPD Editor 70-11 to Props Palette 16-26, 81-10

to selection group 17-9, 17-10

altitude, changing 19-5, 39-13 attaching observer to 50-2 category, changing 65-3 changing

line width 39-17

name 19-6

combat engineering 23-9

concepts 3-8

configuring, avoidance of 73-5 control 37-2

copying 16-21

count 6-4, 18-36

creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11

in plan 36-33


object (continued)

creation, mouse locking 16-18 cultural feature 16-26, 65-9

deleting 65-34

from plan 36-33, 36-34

deleting from simulation model set 65-34 detaching observer from 50-5 disembarking 34-17

dragging 16-19

to new location 34-26 editing 39-12

embarking in Embarkation View 19-10 enabling and disabling creation of 65-7 entity enumeration, changing 65-4 exaggerating models 19-23

fill style 39-17 filtering list of 17-6 geometric 33-18

heading, changing 19-5, 39-13

hiding 9-2, 38-4

ID 15-3, 15-4

intelligence 8-8

intervisibility 46-5

pinning to simulation object 46-10 label 15-5, 18-14, 37-3, 37-9

list 12-10

local 3-9

location, changing 19-5, 39-13 locking mouse to 16-18

Lua 33-3

messages, viewing 18-33

model 64-5, 80-5

moving 16-19

moving to 27-20

multiple, information 18-9

name 65-7

object type, changing 65-4 orbiting 49-13

overlay 37-2

palette 16-4

specfiying 65-7 parameter C-3

default value 12-10

parameters 69-3

editing 65-3

pasting 16-21, 16-22, 16-23

altitude 16-24

placing 16-11 properties

setting 16-3

object (continued) properties

specifying 16-13

remote 3-9

selecting 17-4, 65-3

for creation 16-4

in Objects List Panel 17-6 selecting in multiple list box 26-8 showing and hiding 37-8 subcomponents 69-9

super-type 69-5 timeout threshold B-7 type 69-4

unselecting 17-7 vertex

adding 39-13

deleting 39-15

editing 39-14

views of 17-2

VR-Forces 3-9

object console 18-31

clearing 18-35

notification of messages 18-35 setting notify level 18-32 warning icon 18-35

Object Console Summary Panel 17-4, 18-33, 33-

23, 49-26

answering questions 18-34 selecting simulation object 17-6

object geometry, adding 65-14 Object Group category 16-25 object map file 6-1, 12-2, 12-9

missing back-ends 3-8

object parameter database 3-8, 64-5, 69-2 adding, component in OPD Editor 70-8 component list order 69-16

configuring, sensors 71-2 configuring path to B-3 loading in OPD Editor 70-3 migrating to new release 69-27 pathname interpretation 69-26 reloading B-3

saving 70-12

system definition file 69-17

Object Parameter Database Editor. See OPD Editor

object type mapping 82-4

loading 5-4

published and matching 69-6


object type enumeration C-9 object type mapping

exporting 65-27

importing 65-26

pruning 65-26

objectConsoleNotifyLevel parameter 18-32 objectConsoleNotifyLevel parameter B-4 Object-Map parameter 12-5

objects 16-9, 16-11

Objects Console Summary Panel 18-3

Objects List Panel 17-2, 17-4, 17-6, 19-7, 19-10,

24-6, 25-4

Embarkation View 19-7 selecting object in 17-6

object-type parameter C-3

OBJNAM, attribute 57-26 objTypeEnums.h header file C-9 observer 49-3

adding 48-6, 48-7

altitude, filtering simulation objects by 6-9 attaching

articulated part 50-4

to simulation object or prop 50-2 to simulation objects 50-6

attachment

in 2D 50-15

order 50-3

camera 49-13

changing 77-19

centering on object from Information dialog box 49-26

centering on object from Last Click Object Panel 49-26

centering on object from Object Console Summary Panel 49-26

compass 49-4 coordinate system

2D 49-7

3D 49-7

detaching from object 50-5 dragging

terrain 49-14

view 49-15

heading 49-4 inset view, in 51-2

location and orientation 49-3 LOD, ocean 55-16

mode 48-2

changing 48-3

creating 48-4

observer (continued) mode 48-2

deleting 48-5

editing 48-5

renaming 48-5

setting 4-24

switching projection 48-2 view control message 36-35 XR 48-10

movement 50-7

functions 49-6, 80-2

speed 49-30 moving

keyboard with 49-10

mouse with 49-14, 49-18

orbiting 49-13

orientation 49-15

rain and wave effects 44-2 range for sound effects 47-3 removing 48-9

saving view 49-30

teleporting 49-16 view

attachment change 50-3

saving 49-30

transitioning between 49-32

visibility 11-5

ways to move 49-12 zooming 49-18

2D 49-20

3D 49-19

entity extents 49-22 zooming to extents 49-22

Observer Control Panel 49-28 Observer Information Panel 49-3 Observer Name 77-7

Observer Settings page 18-26, 18-30, 18-31, 19-

25, 19-26, 42-4, 42-5, 42-14, 43-7, 44-3,

45-4, 48-4, 48-5, 48-6, 48-9, 49-5, 49-

24, 49-27, 49-30, 51-10, 53-7

Observer Views Panel 49-31 loading saved views 49-33 saving views 49-33

obstacle 37-2, 37-5

avoidance 19-16

breaching 31-9

configuring avoidance of 73-4 destroying 31-23

fill style 39-17

improving 31-26


obstacle (continued) linear 37-2, 37-5

report 31-30

sending 31-30

obstructed terrain, viewing in terrain profile 46-12 obstruction, configuring avoidance of 73-4 occupancy-director-controller, role in embarkation

73-6

ocean 1-20

choppiness 11-18

depth 55-27

dynamic, enabling and disabling 11-17 effect 11-16

height 55-15, 55-16 height map

regenerating 55-19

resolution 55-17

texture size 55-17, 55-18

layer 55-13

adding 55-15, 55-16

planar reflection 43-8

configuring 43-10

performance 43-10

texture height 43-10

texture width 43-10

quality 11-20

swell 11-18

synchronized 5-6

Ocean Height Map Regeneration Threshold 55-19 ocean height map resolution 55-18

Ocean LOD Elevation 55-16, 77-16

Ocean Settings page 11-20, 43-9, 43-10, 43-14,

44-4, 44-5, 55-18, 55-19

off road driving 26-22 offset

burst 20-8

UV 83-21

offset start time 20-12

OffsetX parameter 83-12

OffsetY parameter 83-12

OffsetZ parameter 83-12

OGR 62-7

driver 57-9

ogr2ogr 62-7

oil 23-13

pacing and tracking 34-21 setting 34-20

opacity

2D label background 18-16

opacity (continued) prop 55-25

setting 55-25 OPD, reloading B-3 OPD Editor 1-18

adding, resources 70-11

changing, component priority 70-9 compared to Simulation Object Editor 64-3 connecting components 70-10

deleting parameters and components 70-7 editing, parameters 70-4

loading object parameter database 70-3 opening from Simulation Object Editor 65-31 restoring values 70-7

saving object parameter database 70-12 starting 70-2

OPE file 69-26, 72-3

Open Cargo Door task 30-13 Open Door task 29-6

Open Model Set dialog box 64-7, 64-16 Open Window task 29-6

OpenAL 47-3

OpenFlight 80-5

converting texture data 61-13 file 52-3

format 1-7, 85-2

OpenGL 61-10

opening

cargo door 30-13

Create Object dialog box 16-13 door 29-6

inset view 51-2

scenario 7-30

simulation model set 64-16 terrain 52-7

window 29-6

OpenSceneGraph 1-3, 1-19

environment variables for anaglyphic stereo 77- 21

license 1-22 operator

boolean 35-14

comparison 35-13

logical 35-14

optimizing, performance 6-4 option

command-line 5-3

element 57-21

navigation 49-12

orbit, observer 49-13


Orbit task 27-23 orbiting

terrain, with mouse 49-15, 49-18

order of battle 6-1, 12-10

file 12-2, 12-10, 38-5

default values in 12-10 ordered speed, setting 34-29 Ordered Speed dialog box 34-29

Ordered Speed set data request 34-29 fixed-wing for 34-29

Order-Of-Battle parameter 12-5

ordnance

unexploded, destroying 31-22 organization

entity of 15-6

unit 22-3

orientation 49-3

camera 77-19

clamping 19-22

displaying 18-11

icon 18-22

observer 49-3, 49-14, 49-15, 49-18, 50-7

prop, changing 55-26

specifying measurement unit 78-11 OSG file 52-3

OSG_CURL_PROXY, environment variable 56- 5

OSG_CURL_PROXYPORT, environment variable 56-5

OSG_ICO, environment variable 6-12 osgEarth 1-19, 56-2, 57-3, 61-14

adding terrain servers 56-4 driver 57-6

license 1-22

osgEarth Boundary Generation Tool 57-14, 57-16 osgEarth Profile dialog box 61-14

osgearth_cache 1-18, 61-5 OSGEARTH_CACHE_PATH, environment

variable 61-3 OSGEARTH_CURL_PROXYAUTH,

environment variable 56-5

outline

emitter volume segment 84-6 segment 84-6

output, port group 69-14

Out-the-Window, observer mode 4-24 out-the-window view 77-17

overlay 1-13

changing name 38-4

concepts 37-2

overlay (continued) creating 38-3 default

adding 65-8

specifying 65-8

deleting 38-5

editing, enabling and disabling 38-3 export to shapefile 38-6

file 12-2, 38-5, 39-7

hiding 38-4

by default 38-4 hiding graphics on 37-8

importing shapefile to 38-7 introduction to 38-2

label 38-4

locking and unlocking 38-3 moving objects between 39-5 object 37-2

selecting 17-4

setting 16-3

tab 38-4

text, adding 39-5

Overlay Layers dialog box 65-8 overlay object

copying 16-21

deleting 39-11

disaggregation area 24-12 moving, to different overlay 39-5 pasting 16-21, 16-22, 16-23

spot report 9-9

Overlay parameter 12-5

Overlays tab 37-8

Overlays view 17-2

Override Position 19-9 overriding

default scenario parameters 7-5 plan 36-42


P

-P command-line option 5-9, 5-13, 5-20

-p command-line option 5-8, 5-13, 60-5 pacing

ammunition 34-9

equipment 34-20

resource 34-34

weapon 34-45

package, scripted task 32-32 page

Add Props 63-20


page (continued)

Audio Settings 47-2, 47-3

Checkpoint Settings 7-26, 7-32, 7-33, 7-34

Date and Time 11-3, 11-4 Detonation Sound Editor 47-9 dialog box, configuring 79-3 DI-Guy Settings 6-20

Display Units Settings 18-23, 37-10

Earth Layers 53-12

Edit Existing Props 55-21 Elevation Color 53-4, 53-5, 53-6

Engineering Object Information 23-12 Entity Behavior Options 24-6, 24-11

Entity Definition Editor 83-2, 83-15, 84-7

Entity Sound Editor 47-5, 47-6, 47-7 Environment Conditions Settings 83-17 Feature Settings 53-15

Fire Sound Editor 47-9

High Dynamic Range Settings 43-11, 43-16

Indirect Fire 10-3, 10-6

Intersector Settings 61-12

Joystick Configuration 75-4, 75-6, 75-7 Local Weather Zones 11-13

Missile Target 10-8, 10-10

Model Definition Editor 83-9, 83-21, 84-5, 84-

6, 84-7

Mouse Mappings 49-18

Navigation Areas 58-3

Observer Settings 45-4, 48-6

Raster Maps 61-7

Render Settings 49-25

Resource Information 18-29 Scenario Event Settings 8-14 Schema Editor 81-12

Sensor Settings 45-4

Session Options 18-18, 18-19, 78-10

Shadow Settings 43-20, 43-21

Supplies 23-12

Symbol Decoration Settings 18-16 Tactical Graphics Settings 39-19 Terrain Contents 55-15

Weather 11-6, 11-7, 11-8, 11-9, 11-10, 11-11,

11-12, 11-17, 77-16

pagecollection, element 79-3

pagecollections, element 79-3

Paged LOD Magnification LOD Angle 49-21 Paged LOD Magnification Scale Factor 49-20 paged terrain

flipping DDS textures 61-11 loading 5-10

paged terrain (continued) preprocessing 56-6

paging

terrain 52-8

manually 56-6 palette

Entity 16-3

Hazards/Obstacles 11-14, 16-4, 16-5, 23-9

object creation 16-4

specifying 65-7

Props 16-3

Tactical Graphics 16-5 panel

displaying and hiding 78-3 dockable 78-2

docking 78-2

floating 78-2

Frame Rate Monitor 6-5 Last Clicked Location 53-16

Object Console Summary 18-33 undocking 78-2

parachuting 34-31 parameter

acceleration-to-rpm-factor 9-18

adding, to model definition 81-15 additional-algorithm-config 72-29 additionalDestinationAddresses B-7 additional-opds 12-6 additionalSystemScriptsDirectory B-2 addMulticastAddr B-7

aggregate-formation-controller 73-2

aggregate-level entity 67-17

aggregate-level unit 67-4

aggregate-object-param 69-25

aggregate-param C-8

aggregateSpatialModelTickAsFastAsPossible-

WhilePaused B-2 aggregateSpatialModelTickPeriod B-2 aggregateSpatialModelTickPeriodUsesRealTime B-2 aggregateSpatialModelTickVariance B-2

allowed-state-repositories-types 72-32

all-tasks-exclusive 26-35

ammo 72-8

angle-of-incidence 72-22, 72-26

angleSegmentMax 84-5 appIdRange B-7 appNumber B-2

assertOnBlockingTerrainCalls 52-8, B-2

Attach Components to Remote Entities On 7-5 attack, editing 67-22


auto-reorganize 12-5 batchScenarioFileName B-2 can-be-radar-jammed 23-17

can-pivot 27-28

catastrophic-kill 72-26 cgfDispactherReceivePort B-2 ChannelKeyword 83-12 commenting out A-3

comm-model-name 74-4

Component Attachment Table 7-6 component list order 69-16 Component-Attachment 12-5

Component-Attachment-Table 12-5 component-manager C-5, C-7 configName 83-19, 83-21 countryCodesMappingFile B-2, B-4 Create_Global_Dynamic_Terrain 12-6

Create_Global_Environment 12-6

create-script-id 32-21

cultural-feature-param 69-12, C-8

daemon B-2 datumShiftX B-3 datumShiftY B-3 datumShiftZ B-3

daylightControlledLights 43-7

daylight-illumination 71-13

day-night-transition-time is 71-13 defaultHeartbeatThreshold B-7 defaultObjectTimeout B-7 DefaultObserverView 12-6

defaultParameterDatabasePath 12-7, B-3

defaultTerrainDatabasePath 12-7, B-3

defense, editing 67-23

definitions 70-4

delay 72-29 deleting

from model definition 81-18 in OPD Editor 70-7

destAddrString B-7

destroyFedExec B-6

destroy-script-id 32-21

detection-types 72-6

detonation-munition 72-29

detonation-on-destroy 72-29 deviceAddress B-7 diGuyAnimationsFile B-3 DIS B-7

disabled-by-suppression 26-34

disableParallelTick B-3

Display Terrain 7-6 disPort B-7 doNotUseConsole B-3

dr-allow-gui-overrides 6-16

dynamic-terrain-type 72-29

echelon-level 69-25

editing in OPD Editor 70-4

editing in Simulation Object Editor 65-12

egress-points 73-6

electronic warfare, editing 67-23

embarkation-slot-entry 73-6

embarkation-slots 73-6 enableDebugDrawer B-3 enableLogFileTimestamps B-3 enableNavigationLabDebugging B-3 entity-range 72-9

entity-type 72-9 entry C-2

entVrfDataTimeThreshold B-3

equipment, editing 67-24

execName B-6

exerciseId B-7

exercise-start-time 12-6 federateName B-6 federateType B-6 fedFileName B-6 Filename 83-11

firepower-kill 72-26

fixed-wing-entity-param C-8 fomMapperInitData B-6 fomMapperLib B-6 forceParameterDbReload B-3 Frame Mode 7-7

Frame Time 7-7

frame-mode 4-19, 12-6

time management 4-18 frameRateStatisticsLogFile B-3 frame-time 12-6 gamewareMemorySize B-3 ground-vehicle-param 69-3 ground-vehicle-param C-8 guidance-mode 72-18

GuiObserverViews 12-6

GuiScenarioSettings 12-6

Gui-Terrain-Database 12-5 heartbeatVariance B-7 HLA B-6

hostAddressString B-6, B-7

hostile-fire-only 26-34


parameter (continued)

human-param 69-12, C-8

improve-script-id 32-21

ingress-points 73-6

initial-road-preference 34-28

instrumentPanelCategory 51-7

jamming-defense-factor 23-17

jam-strength-factor 23-18

lateral-clearance 73-4

leader-promotion-id 73-3

load-entry 73-6

load-entry-point 73-6 loadPluginIfVersionMismatch B-4 local-objects 69-9, C-4 localSettingsDesignator B-6 logFrameRateStatistics B-4 logger-files-path 7-38

Lua, table 33-15

max-detonation-distance-for-passing-rounds 26-34

maxDrainInputReads B-7 maxDrainInputTime B-4 maximum sheaf 67-12

max-range 28-19

max-range-altitude 28-19

max-slope 26-28

max-speed 34-29

max-thrust 26-28 mcastTtl B-7 message-timeout 13-3

metaFileName 83-19, 83-20, 83-21

mimModule B-6 minDrainInputTime B-6 min-tick-period 6-13

min-tick-period-variance 6-13

missile-param C-8

mobility-kill 72-26

model definition, editing 81-15, 81-17

movement 67-19 moving-object-param C-8 munition-type 72-37

mutually-exclusive-task-groups 26-35

navigation-preference 34-28

net-interface-min-tick-period 6-14, C-5, C-7

net-interface-min-tick-period-variance 6-14, C-5, C- 7

network-interface C-5, C-7

night-illumination 71-13

notifyLevel B-4

number-of-runs 7-38

parameter (continued) object 69-3, C-3

editing 65-3

objectConsoleNotifyLevel 18-32 objectConsoleNotifyLevel B-4 Object-Map 12-5

object-type C-3

OffsetX 83-12

OffsetY 83-12

OffsetZ 83-12

Order-Of-Battle 12-5

Overlay 12-5

parameter-type 69-3, 69-8, 69-12, 69-26, C-2,

C-3

passing-rounds-suppress 26-34

personnel, editing 67-24

Perspective 83-11

PerspectiveHeight 83-12

PerspectiveWidth 83-12

physical 67-18

Plan 12-5

plan-manager C-5, C-7 pluginsDirectory B-4 position-offset 73-3

power-plant-active 9-18

power-type 72-29

promotion-id 73-3

providing information to components 15-8

publish-transmitter 74-4

publish-transmitters 74-4 publishZeroVelocityWhenPaused B-4 Radio Button Choice 32-15 Random Number Seed 7-7 random-number-seed 12-5

range-determinant 72-9, 72-26

range-from 72-19

range-list 72-9

recvBufferSize B-8 rejectMismatchedScenarioMessages B-4 relative-heading 19-14

relative-position 19-14

remote-objects 69-9, C-6 reuseEntityIdentifiersOnScenarioLoad B-4 rotary-wing-entity-param C-8

RotDir 83-18

RotOffsetDeg 83-18

round-down 72-22 rprFomVersion B-7 RSOName 83-11

RTI_timeMgmt 4-18


RTI_useRtiExec 4-18

run-duration 7-38

run-duration-time 12-6

runInTimeManagementMode 4-19, B-7 scenario

file 12-4

setting 7-5

Scenario Name 7-5

scenario-data 12-6

ScenarioDescription 12-6

ScenarioExtentInformation 12-6

Scenario-Extras 12-5 scenarioFileName B-4 scenario-filename 7-38

scenario-name 12-6

Scenario-Scripts 12-5 schema

adding 81-7

deleting 81-8

editing 81-8

script 32-13

script-ids 32-21

SelectionGroups 12-5 sendBackendLogToNetwork B-4 sendBufferSize B-8 sendFedTime B-7

send-spot-reports-on-own-force 9-7

sensor, editing 67-21

separation-distance 26-11

separation-tolerance 26-11

sessionId B-4 setDeadReckoningAlgorithmToStaticOnPause B-5 setMainThreadToHighPriority B-5

setting simulation object 34-4 showLines 84-6 simMgmtPduProcessLevel B-5 Simulation Model Sets 7-6 Simulation Object 32-16

Simulation Terrain 7-5 simulationModelSet B-5 Simulation-Model-Set-Files 12-6

simulation-run-duration 7-38

siteId B-5

sms-filename 7-38

soil-list 19-17 specifying for task 26-7 speed-to-rpm-factor 9-18 spheroidSemiMajor B-5 spheroidSemiMinor B-5

standard-power-type 72-28

standard-terrain-damage-type 72-28

startInRunMode B-5

startMinimized B-5

state-repository C-4, C-6

state-repository-min-tick-period 6-14

state-repository-min-tick-period-variance 6-14

statusUpdateHeartbeat B-5 stopping-distance-factor 73-4 structure of entries C-2 subnetMask B-8

substitute-message-size 13-3 subsurface-entity-param C-8 sunrise-time 71-13

sunset-time 71-13

supplies, editing 67-24

suppression-degrades-sensor-performance-by 26-35

suppression-detonation-insult 26-34

suppression-detonation-range 26-34

suppression-insult-level 26-34

suppression-recovery-time 26-34

suppressSelfReflect B-8 surface-entity-param C-8 targetFrameRate B-5 targeting-capable 34-18

targeting-control 72-6

task, Lua 33-17

task-manager C-5, C-7 taskVisualizationPublicationMode B-6 terrain-check 26-31

Terrain-Database 12-5 terrainDatabase B-6 Time Multiplier 7-6

time-multiplier 12-5

tracer-type 72-8

underFireDistance 34-36

underFireTime 34-36 useAbsoluteTimeStamps B-7, B-8 use-actual-message-size 13-3 useAdvisories B-7

useAsyncIO B-8 useCustomMapDatum B-6 useDIGuy B-6

useDrawControlForTaskVisualizations B-6

useIpv6 B-8

use-logger-control 7-38

using remote entities as 35-19

value, restoring in OPD Editor 70-7

vel-to-align-actual 26-32


parameter (continued)

vel-to-align-desired 26-32

visual definition, editing 81-29

vrf-base-object-param 69-26, C-3

wakeLength 11-19

warhead 72-8

warhead 72-18

WindSpeed 83-18

WindState 83-18

parameter-type, control object 69-26

parameter-type parameter 69-3, 69-8, 69-12, 69-26,

C-2, C-3

parent

disembarking from 19-12

element 81-27

element definition 81-21

parent, attribute 83-6 particle effect, sea spray 44-4

passing-rounds-suppress parameter 26-34

passive sonar 9-17 paste

special, altitude 16-24

Paste Special 16-23 pasting

appearance 16-23

objects 16-21, 16-22, 16-23

performance and 16-21

plans 16-22

simulation object 16-23

patch, terrain 52-3 path

data 3-12

finding 3-14

following 3-15

planning 3-14, 27-18, 27-21 using road data 34-28

specifying for RTI 2-9 pathname

interpreting by object parameter database 69-26 scenario files 12-7

Patrol Between dialog box 27-24 Patrol Between task 27-24 Patrol Route dialog box 27-23 Patrol Route task 27-23 patrolling

between objects 27-24

route 27-23 pattern

color 57-24

editing condition 36-24

pattern (continued)

in condition 36-22, 36-24

Pattern Hold (Location) dialog box 27-24 Pattern Hold (Location) task 27-24 Pattern Hold (Waypoint) dialog box 27-25 Pattern Hold (Waypoint) task 27-25 Pattern tab 36-24

pause

scenario, using PDU 7-41 pause mode B-5

pausing

scenario, automatically 7-7, 7-35

simulation 7-25 PDU

sending 48-11

siman, configuring B-5 Start/Freeze 7-41

Start/Resume 7-41

Stop/Freeze 7-41

Underwater Acoustics 9-17

view control 49-34

pedestrian, creating 21-2

pedestrian area 21-9 adding entities to 21-3 adding pedestrians 29-3

creating 21-2

pedestrian path 27-13

control object 21-9, 37-2 pedestrians, adding to crowd 29-3 pen style 39-17

Pen Style dialog box 40-6

Pen Style set data request 40-6 Percent Complete dialog box 34-29

Percent Complete set data request 34-29 performance 6-8, 6-9, 6-14, 49-19, 55-17

affected by copy and paste 16-21 anti-aliasing 5-3

asynchronous I/O 5-20, 6-12

attached observer 50-6 coloring draw calls 6-18 compressing texture 61-6 cube map calculation 43-14 DI-Guy 6-19

factors affecting 6-3

frame rate 5-12, 6-17

function profiler 6-8

graphics, depth 5-3

HAT lines 18-23, 37-10

improving 6-11

instancing 5-5


performance (continued) interest management 6-8

load balancing 7-19

main thread 5-11

model, best practices 83-26 network, tuning 6-15

ocean planar reflections 43-10 optimizing 6-3, 6-4

setting application priority 5-4 shadows 43-21

statistics, displaying 6-6

stencil bits 5-7

streamed data 6-12

terrain 55-4 tuning

network interface 6-14

state repository 6-14

visual for 3D application 6-15 visual 6-19

zooming in 49-21

Performance Options dialog box 6-15, 6-16

Performance Options page 6-15, 6-17

period, burst 20-8 periodic checkpointing

disabling 7-32

scheduling 7-32

periodic snapshot, enabling 7-34 periscope

lowering 30-12

raising 30-13

permanent intervisibility object 46-5 personnel, status 18-7

personnel parameter, editing 67-24 perspective, in display 77-14 Perspective parameter 83-11

PerspectiveHeight parameter 83-12

PerspectiveWidth parameter 83-12

phase line 37-2, 37-4 Entity Left of Line 35-12

physical model 15-9

physical parameter 67-18

physicalWorldParams.mtl, file 71-9 pinning

range rings 18-26

sensor contact lines 42-14 task visualization 42-13

pitch 49-3

Pitch updater 83-12

pixel 83-26

Place IED dialog box 28-16

Place IED task 28-16 placing 16-11

IED 28-16

new entity 19-3

props 16-11

simulation objects 16-11

tactical graphics 16-11 plan

abandoning 25-1, 36-42

confirmation prompt 26-6 from a plan 36-42

adding

statement 36-4

task 36-4

aircraft 35-19

altitude condition 35-10

assigning to multiple simulation objects 36-39 concepts 34-1

condition, If 36-5

conditional statement 35-4 considerations for creating 36-3 console message, sending 36-33 copying 36-40

creating object 36-33

custom 20-2, 20-9, 20-12

default 20-2, 20-9, 20-13 deleting

object 36-33

simulation object 36-34

statement 36-10

drag and drop statement 36-40 editing 36-3

statement in 36-9

entity 35-2

when aggregated 24-11

file 6-1, 12-2

editing 12-8

Follow Entity task 35-18 force hostility 9-12

global 11-2, 35-2

writing 36-26

global command, adding 36-30 global task, view control 36-35 including scenario events 8-11 individual 11-2

inverting condition parameter 36-22 issuing 36-34

manager C-5

Move to Location task 27-17


plan (continued)

name in condition 36-23 pasting 16-22, 16-23 pattern in condition 36-24 printing 36-10

remote simulation object 35-19, 36-39

restarting 36-41

saving 36-10

simulation time condition 35-13 Tasked by Superior 35-18 trigger 35-7

unit, for 24-12, 36-39

variable 35-15

viewing 35-16

When statement 35-7

While condition 35-9

writing 36-3

Plan parameter 12-5

plan view 48-10

Plan View window 4-13

Plan window 35-16, 36-3, 36-4, 36-5, 36-6, 36-7,

36-10, 36-40

planar reflection 43-8

plan-manager parameter C-5, C-7 planning, path 3-14, 27-18, 27-21

plant, avoiding 19-16 platform

regenerating 70-12

specifying 65-8

update, applying 64-19

platform file 69-16 variable binding adding 69-22

adding to Simulation Object Editor 69-23 variable bindings 69-21

platoon, preconfigured 24-5 playing, scenario event 8-10 plug-in

adding 4-34

configuration, deleting 4-36 DLL

removing 4-35

specifying 4-35

list, viewing 4-37

loading 4-32, 4-33, 5-3, 5-5, 5-6, 5-10, 5-17

managing 4-31

prevent loading 5-7

version, checking 5-3

XML file 4-34

deleting 4-37

Plug-ins dialog box 4-32

Plug-ins Editor 4-32, 4-34, 4-35, 4-36, 4-37

pluginsDirectory parameter B-4 PNG 52-4

point 37-4

civilian visit 21-9, 21-10 feature, list of 53-14 moving to 27-20

orbiting around 49-13

patrolling between 27-24

reversing 39-16

strong, constructing 31-21

suppressive fire at 26-32, 28-17 terrain profile, sampling rate 54-3

point feature, in front-end and back-end 52-5 point-to-point communications

configuring B-7 specifying 5-20

point-to-point intervisibility 46-3

POL, status 18-7

polarized stereo 77-20

configuring 77-22 policy

Distance To Attached 77-10 Reduce Near Clip 77-10 Reduce Z Fighting 77-10

polygon 37-5, 52-7, 83-26

count 55-4

not going through 49-28 terrain, viewing 53-18

underwater 55-27

popup menu 78-9, 79-5

port 15-8, 69-14

default 5-20

for scenario files B-2 group 15-8, 69-14 number B-7

specifying at startup 5-20 proxy 56-5

specifying, at startup 5-20 position 49-3

camera 77-19

observer 49-14, 49-18, 50-7

prop, changing 55-26

window attribute 77-6

position-offset parameter 73-3 posture

adding 67-26

affect on footprint, sensing, sensor signature, speed 23-5


posture (continued) changing 31-11, 34-30

Deliberate-Attack 23-4

Deliberate-Defense 23-4

Hasty-Attack 23-4

Hasty-Defense 23-4

Reconnaissance 23-4

Rout 23-4

setting 34-31

transition time, editing 67-21 Travel 23-4

unit 23-4

Posture dialog box 34-30, 34-31

Posture set data request 34-30, 34-31 power

adding new 72-23

combat 23-3

determinant 72-19

explosive 72-15

power-list block 72-18

power-plant-active parameter 9-18

power-type parameter 72-29

precedence, components in OPD 69-16 precipitation 11-5, 11-8

intensity 11-12

type 11-12

preconfigured unit 24-5

Prefer Roads 34-28

preferred movement mode 29-7 preferred road data 29-7

Preferred Targets dialog box 34-32 preprocessing

terrain, paged 56-6 primary color, unit 25-11

primary simulation object 50-10, 50-13 printing

plan 36-10

window 4-13 priority

component, changing 70-9

weather zone 11-13

prisoner-of-war 34-42

probability, damage 72-21

probability table, direct and collateral damage 72- 10

probability-coefficient list 72-9 process

background 33-30 object mappings to 12-9 VR-Forces 3-2

process ID, front-end 5-9 processing

MetaFlight 60-3

streamed data 57-7 product

technical support lvi upgrades lvi

profile, navigation data 58-6 profiler, function 6-8 projected terrain database 49-7 projection

supported 1-13 switching 2D to 3D 48-2

Projection Resize Policy 77-7 configuring 77-11

Projection Units 77-7

promotion-id parameter 73-3 prompt

confirmation, abandoning plan 26-6

task confirmation, enabling or disabling 26-6 prone 34-31

prop 16-10, 52-5

adding

from feature layer 55-22

to Props Palette 16-26, 81-10, 83-13

to terrain 55-19

attaching observer to 50-2, 50-6

configuring 52-4

creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,

16-26, 83-13

extracting 55-20, 63-20

from terrain 52-4 filtering attachment list 50-5 heading, setting 16-17

model definition, changing 55-26, 63-23

opacity 55-25

opaque 55-25

placing 16-11

saving 16-26, 83-13

transparent 55-25

type 55-26

viewing list of 55-24 property

channel 77-7

editing system 65-31

object, setting 16-3

tactical graphic, default 65-54 window 77-6

Props Palette 16-3, 16-4, 16-5, 16-11

adding objects to 16-26, 81-10, 83-13


Props Palette (continued) category, adding 83-14

propulsion noise 9-17, 9-18 Protest Along Line dialog box 29-7 Protest Along Line task 29-7

Protest Around Location dialog box 29-7 Protest Around Location task 29-7 protesting, crowd 29-7

Provide Suppressive Fire on Location task 26-32, 28-18

Provide Suppressive Fire task 26-32, 28-17

providing, supplies 23-15

proximity detonation 72-16

proximity fuse 34-15

proximity sensor 72-16 proxy

connecting through 56-5

port 56-5 pruning

element definitions 65-26

model definitions 65-26 object type mappings 65-26 visual models 65-26

published object type 69-6 publishing

entity velocity when paused B-4 radio trasmitter 74-4

tactical graphics 39-7

publish-transmitter parameter 74-4

publish-transmitters parameter 74-4 publishZeroVelocityWhenPaused parameter B-4 pulse repetition rate 84-2


Q

-q command-line option 5-11 Qt Designer 69-23

UI file, details 69-24 Qt Linguist 2-10

quadcopter 27-25, 27-26

quality, ocean 11-20 query

feature 62-6

named 62-3 question

asking from script 33-23 scripted task 18-34

Quick Launch toolbar 8-10 quitting

plan 36-42

quitting (continued) retask procedure 26-7


R

-r command-line option 5-11, 60-5

radar 34-33

jamming 23-16, 23-17

sensor 34-18 radar mode

search 34-33

track 34-33

Radar Mode dialog box 34-33 Radar Mode set data request 34-33

Radar-Jamming-Strength-Receiving 23-17

radio 34-11, 34-15

communication line 42-20

color 42-23

enabling and disabling 42-21 lifetime 42-22

configuring 74-4 message

configuring 13-2

set data request 30-7 task 30-9

Radio Button Choice parameter 32-15

Radio Communications Settings page 42-21, 42-

22, 42-23

radio transmitter, publishing 74-4 radius

emitter volume 84-3

sheaf 31-27

rain 11-5, 11-8

intensity 11-12

splash effect 44-2

Raise Periscope task 30-13 random

DI-Guy appearance 65-17

simulation object 16-25

Random condition 35-13

Random Number Seed parameter 7-7 randomized simulation object 65-43 random-number-seed parameter 12-5 range

focal 49-23

ground clamping 19-22

intervisibility line 46-11

laser codes 9-15

Simulation Time Scale Toolbar, changing 7-25


range ring 18-24

configuring display of 18-27 displaying for entity 18-26 enabling and disabling 18-26 pinning 18-26

sensor 18-24

Range Rings Settings tab 18-27 range-coefficients determinant 72-20

range-determinant parameter 72-9, 72-26

range-from parameter 72-19

range-list determinant 72-20

range-list parameter 72-9 raster map

display order 55-10

displaying 55-7

Raster Maps page 55-7, 55-10, 61-7, 63-5 rate

climb, turn, and descent 27-10 turn 27-9

ray

crepuscular 43-12

intervisibility 46-4

sun 43-12

reactive task 21-10, 26-12, 30-19, 32-5, 33-8, 33-

29

canceling 26-18

creating 32-27

disabling 26-15

enabling 26-14

Visit Interest Points 21-10 reader writer key value pair 67-26 Real DB 1-21

real time

checkpointing in 7-32

running faster or slower than 3-11 recalling

view 49-31

view state 49-30

receive buffer size 5-9, 5-13, B-8 Receive Text Message condition 35-13 receiving

radio messages 74-4

supplies 23-15

recently used scenario 7-18 Reconnaissance, posture 23-4 recording, to Logger 7-41 recovering, embedded entity 30-14 recovery 34-11

recvBufferSize parameter B-8

redo, ellipse rotation 39-16

Reduce Near Clip, policy 77-10 Reduce Z Fighting, policy 77-10

Reduce Z Fighting Ratio, attribute 77-10 reference ellipsoid B-3, B-5

configuring B-6 reflection

map 1-15, 61-7

planar 43-8

refresh rate 6-19

refreshing, visual models 65-27 refueling boom 30-12, 30-13 regenerating

ocean height map 55-19 platform 70-12

regenerating spot report definition 65-21 region

DDM 6-9

update threshold 6-9

register, trigger 35-8

Register Trigger dialog box 36-8 registering, triggers 36-8

registrant_feature_list.csv 57-7

regulating, time 4-17 rejectMismatchedScenarioMessages parameter B-4 rejoining exercise 3-7

relative path 12-7

relative-heading parameter 19-14

relative-position parameter 19-14

Release Bomb on Laser Spot task 28-18 Release Bomb on Location task 28-19 Release Bomb on Target task 28-19 reloading, visual models 65-27 remapping

back-ends 3-8

batch mode 7-39 remote

attachment, key-names 76-3

control 1-16

of the observer 49-34

entity, attaching components to 7-5, 76-2

object 3-9, 69-9, C-6

network interface 69-12

simulation object 3-9, 26-3

markings 35-19

plan 36-39

use in plans 35-19

stealth, displaying model 48-12 remoteAttachment example scenario 76-2 remoteConfigurations directory 76-3

remote-configurations entry 76-3


remote-objects parameter 69-9, C-6 removing

assembly 67-13

category 64-19, 64-20

channel 77-5

force 64-24

formation 66-10

navigation area 58-5

object from Favorites list 16-27 objects from selection group 17-10 observer 48-9

simulation objectfrom unit 24-8 subordinate 66-5

system 65-32

triggers from plan 36-9 view 49-32

window 77-5 renaming

category 64-19, 64-21

formation 66-10

observer mode 48-5

overlay 38-4

scenario 7-29

selection group 17-10

Render Settings page 6-7, 6-8, 6-18, 43-13, 49-25,

53-11, 61-9, 77-13

Reorganize set data request 34-33 reorganizing

concepts for units 22-4 unit 34-33

versus closing formation 22-5 repair 34-11

repeat image attribute 55-8 replace image attribute 55-8 replacing

saved view list 49-33 subordinate 66-6

replicating, settings and data 4-23 report

NBC 31-29

obstacle 31-30 repository C-4

require statement, Lua 33-6 Reserve Space 19-9

resizeable window 77-2 resizing

boxes and text overlay objects 39-15 windows 77-11

resolution

ocean height map 55-18

resolution (continued) tree 83-22

resource

adding to object 70-11 information 18-4

monitoring entity 18-29 pacing and tracking 34-34 specifying 34-34

status at creation 19-4 tracking unit 24-10

Resource condition 35-13 Resource Information, page 18-29 resource-item, adding 67-26 Resources dialog box 34-34

Resources Pacing/Tracking dialog box 34-34 Resources Pacing/Tracking set data request 34-34 Resources set data request 34-34

Restart Plan command 36-41 restarting, plan 36-41

Restore set data request 34-35 restoring

embedded entity parent 19-15 parameter values in OPD Editor 70-7

simulation object health and stores 34-35 unit 24-10, 34-35

view 49-31

restriction, unit movement 62-9 result

detonation, sound mapping 47-8 resuming, simulation 7-24

resupply 23-15, 34-11

modes 34-35

Resupply Mode dialog box 34-35 Resupply Mode set data request 34-35 retreat 31-28

retrograde movement 31-28 reusable software object 83-10

reuseEntityIdentifiersOnScenarioLoad parameter B-4

Reverse Direction 27-13 reversing, line direction 39-16 reverting

category changes 64-21 navigation area edits 58-5 parameter values 70-7

window layout 78-6

revision, RPR FOM 5-8, 5-13

revolving, observer 49-13 rewinding

scenario 7-25, 7-30

scripted task 32-30


rewinding (continued)

to a snapshot or checkpoint 7-25 RGB 52-4

RID file 2-9, 5-17

rid.mtl file 2-9, 5-17

right-click menu 78-9

configuring 79-5

rightclickmenu, element 79-5

ring, range 18-24 road

data, using in path planning 34-28 driving on 26-23

network 26-22 using route as 27-13

roll 49-3

roll up, rule 67-14 Roll updater 83-13

rolling back to a snapshot 7-25 rolling up assembly 67-15 rope, sliding down 27-6

Rotary Wing Airlift Cargo to Location task 27-25 Rotary Wing Land dialog box 27-26

Rotary Wing Land task 27-26

Rotary Wing Retrieve Cargo task 27-26 Rotary Wing Unload Cargo task 27-27 rotary-wing, landing at airport 27-12 rotary-wing entity

altitude 27-8, 27-10 attacking with gun 28-3 creating, routes for 39-10 heading 27-9, 27-10

holding pattern 27-24, 27-25

landing 27-26

lateral movement, configuring 26-32 routes for 39-10

terrain avoidance 26-31 writing plans for 35-19

rotary-wing-entity-param parameter 69-12, C-8

rotary-wing-entity-state-repository 69-12

rotating, ellipse 39-16 rotation path, smoothing 6-16 RotDir parameter 83-18

RotOffsetDeg parameter 83-18

rotor wash 44-2

high quality 44-5

roughness type, mapped to soil type 19-17 round 10-2

round-down parameter 72-22

Rout, posture 23-4

route 37-2, 37-5 altitude

displaying 37-10

setting 16-16

computed, creating 39-7 evaluating for aircraft 39-10 extruded 39-4

following 27-13

fixed-wing 26-27

for aircraft 39-10

patrolling 27-23 using as road 27-13

RPR FOM 5-18

revision 5-8, 5-13 specifying version B-7 version 5-8, 5-13

rprFomVersion parameter B-7

RSO 83-10

RSOName parameter 83-11

RTI 2-8

configuring for time management 4-18 definition of 2-8

RTI_CONFIG environment variable 2-9

RTI_timeMgmt parameter 4-18

RTI_useRtiExec parameter 4-18

rtiexec 4-18

rule, roll up 67-14 rules of engagement

pasting 16-23

setting 34-36

Rules of Engagement dialog box 34-36 Rules of Engagement set data request 34-36 run

scenario, using PDU 7-41 run mode B-5

starting back-end in 5-11

run-duration parameter 7-38

run-duration-time parameter 12-6 runInTimeManagementMode parameter 4-19, B-7 running 34-31

batch scenario 7-39

Boundary Generation Tool 57-16 simulation 7-24

runway 26-28

rwKeywordValuePairs.xml 67-26


S

-S command-line option 5-7, 5-8, 5-13, 5-20, 50-

6


-s command-line option 5-11, 5-15, 60-5 S-57

buoys and beacons 57-23 converting to shapefile 62-7 data 55-27

signal sequence 57-31

s57_attr_map.csv 57-25, 57-28

s57_defaults.csv 57-28

s57_layer_list.csv 57-23, 57-28

s57_modeldef_by_name_map.csv 57-26 Sail Heading dialog box 27-27

Sail Heading task 27-27 salvo 10-2

sample, scenario 7-23 sampling rate

freehand line 39-2

intervisibility, configuring 46-9 San Luis Obispo terrain 53-20 Save Scenario dialog box 7-28 saved views file 6-1

scenario 12-2 saving

checkpoint 7-30

display engine configuration 77-5 element definition 81-32

global variables 33-14 hierarchy and leaves 81-36 model definition 81-20

object parameter database 70-12 plan 36-10

prop 16-26, 83-13

scenario 3-7, 7-27, 7-30

existing 7-29

under new name 7-29 schemas 81-4

scripts 32-30

settings 4-21, 4-23

tactical graphics 38-5

terrain 55-4

view 49-30, 49-31

to file 49-33

window layout 78-3, 78-6 scale

factor, material ambient and diffuse value 43-4 SpeedTree, random 83-24

terrain 53-17

Scaled Speed check box 49-29 scaling

3D models 19-23

icon, 2D 18-21

scaling (continued)

model, linear and XR 19-23 scenario 6-1

batch 7-37

building blocks 7-16

checkpoint 7-30

checkpoints and snapshots 7-30 closing 7-27

collaborative development 7-12 component attachment table 7-6 compressed format 6-1, 12-2

creating new 7-3

date, setting 7-7

description, editing 7-23

end time 7-7, 7-35

new scenario 7-35

file 3-7, 6-1, 12-2

editing 12-3

parameters 12-4

pathnames 12-7

specifying which to use B-4 format, saving to different 7-29 frame mode 7-7

frame time 7-7

importing 7-12, 7-16

information, displaying 7-21

loading 5-7, 5-10, 7-17

at startup 5-10

recently used 7-18

merging 7-12

MSDL, importing 7-14

name 7-5

order of battle 12-10 parameter

setting 7-5

version 12-6

random number seed 7-7 remoteAttachment 76-2

renaming 7-29

reopening 7-30

resuming 7-24

rewinding 7-25, 7-30

scripted task 32-30

rolling back to snapshot or checkpoint 7-25 running 7-24

sample 7-23

saving 3-7, 7-27, 7-30

existing 7-29

under new name 7-29 simulation model set 7-6


scenario (continued) SMS, multiple 7-8

starting 7-24

starting date and time 7-11 default 7-12

startup observer view 49-32 temporary directory 12-11

terrain 12-8

display 7-6

simulation 7-5

time, setting 7-7

time multiplier 7-6

zoom to extents on load 49-22 scenario event 8-2

adding audio, video, and graphics 8-5 creating 8-3

deleting 8-13

ending 8-12

intelligence object 8-8

sending 8-10

sending from plan 8-11 Scenario Event condition 35-13 Scenario Event dialog box 8-11

Scenario Event Manager 8-3, 8-8, 8-10, 8-12, 8-13 Scenario Event Settings page 8-14

Scenario Event Toolbar 8-2 scenario extras file 12-2, 20-9

Scenario Information dialog box 7-23 Scenario Name parameter 7-5 scenario script 32-3

Scenario Snapshots dialog box 7-26, 7-31, 7-33, 7-

34

Scenario Startup dialog box 4-6, 4-7

Scenario Toolbar 7-33

scenario-data parameter 12-6

ScenarioDescription parameter 12-6

ScenarioExtentInformation parameter 12-6

Scenario-Extras parameter 12-5 scenarioFileName parameter B-4 scenario-filename parameter 7-38

scenario-name parameter 12-6

Scenario-Scripts parameter 12-5 scenario-specific

GUI settings file 12-2 spawn pattern 20-9

scheduling

periodic checkpoint 7-32

spawn event 20-6

schema 81-4

copying 81-6

schema (continued) creating 81-5

deleting 81-6

model definition 81-4 parameter

adding 81-7

deleting 81-8

editing 81-8

saving 81-4

tactical graphic model 65-56 visual definition 81-4

Schema Editor page 81-5, 81-6, 81-7, 81-8, 81-12

SciTE 32-4

scnx, file 6-1, 12-2

Screen Number attribute 77-6 script

adding to task toolbar 32-23 availability, by simulation object type or

Behavior Set 32-19

creating 32-6

deleting 32-34

extended name 32-12

ID 32-21

location, object 33-18

making available by Behavior Set 32-21 metadata 32-5

parameter types 32-13 previewing dialog box 32-10 saving 32-30

script, editing 32-38

script ID 32-8, 32-11 set data request 32-3

simulation object type supported 32-20 system and scenario 32-3

Task menu location 32-17 Script Options page 32-37 scripted

behavior 27-3

movement, configuring 65-47

scripted set 32-5

creating 32-26

scripted task 32-3, 32-4

actioncategory 26-36 adding to folder 32-32 adding to toolbar 79-6 background process 33-30

copying 32-34

editing 32-30

entry point 33-7

execution flow 33-9


scripted task (continued) exporting and importing 32-32 filtering list 32-31

folder

adding 32-31

deleting 32-32

renaming 32-31

importing 32-33

in system definition 32-21 interactive 33-23

language 32-25

organizing 32-31

package 32-32

question 18-34

reactive task 26-12, 33-8, 33-29 removing from folder 32-32 rewinding 32-30

script ID 33-15

script storage location 32-32 system

creating 32-35

making available on Task menu 32-35 storage location 32-35

Update_EW_Degradation 23-17

script-ids parameter 32-21

scripts file 12-2

scriptstext editor, specifying 32-37 sea

choppiness 11-5

spray 44-2

enabling and disabling 44-4 state 11-5, 11-18

Douglas 11-16

swell 11-5, 11-18 sea spray, size 44-5

search, radar mode 34-33 search and rescue 28-20, 30-15

seasonal buoys and beacons 57-30 secondary

simulation object 50-10, 50-13

window 4-13

sector, unit 18-24, 23-4

sector of responsibility, setting 34-37 Sector of Responsibility dialog box 34-37

Sector of Responsibility set data request 34-37 Sector Search Operation dialog box 28-20, 30-15 Sector Search Operation task 28-20, 30-15 segment

angle, setting 84-5

arc size 84-5

segment (continued) edge 84-6

emitter volume 84-4

outline, displaying 84-6

Selected Simulation Engine Toolbar 16-6, 16-8 selecting

database for front-end 7-3

entity, from Object Console Summary Panel 17-6

object 17-4

in Objects List Panel 17-6 multiple list box 26-8

to create 16-4

objects 65-3

observer 48-6

selection group 17-9

simulation objects 17-5

unit 24-6, 25-2

selection box 17-5

selection group 21-5

adding object to new 17-9 adding to 17-10

creating 17-8

creating from keyboard 17-9 creating from menu 17-9 deleting 17-10

file, scenario 12-2

introduction 17-7

removing object from 17-10 renaming 17-10

selecting 17-9

Selection Group View 17-2 SelectionGroups parameter 12-5 self, as condition parameter 36-22 self reflection, DIS 5-13

send buffer size 5-9, 5-13, B-8

Send NBC Report dialog box 31-29 Send Obstacle Report dialog box 31-30 Send Radio Set task 30-7

Send Radio Task task 30-9 Send Text Message task 30-10

sendBackendLogToNetwork parameter B-4

sendBufferSize parameter B-8 sendFedTime parameter B-7 sending

console message 36-33 data, configuring B-3 messages 15-9

NBC report 31-29

obstacle report 31-30


sending (continued) radio messages 74-4

scenario events 8-10

from plan 8-11

set data request via radio message 30-7 task via radio message 30-9

text message 30-10

view control, in plan 36-35

send-spot-reports-on-own-force parameter 9-7

SenSim 45-2

sensing, electronic emission 23-16 sensing target 72-6

sensor 9-13, 15-8, 15-9, 71-2, 72-6

See also. sensor signature adding new 71-9

affect of posture 23-5 aiming 34-38

attaching to remote entity 76-2 channel attribute 77-7

configuring 71-2

connecting 71-3

detection types 71-9

emission 23-18

footprint 23-8

information 18-4 mode, full color 45-5

parameter, editing 67-21

proximity 72-16

radar 34-18

range ring 18-24

sensor contact line 42-13 SIGINT 23-18

signature-object-sensor 71-2

system 65-28

system definition file 69-17 editing 71-4

unit 23-8

visual, illumination 71-12

zooming 34-39

Sensor Aim set data request 34-38 sensor component, adding 71-11 sensor contact line

configuring 42-15

enabling 42-14

enabling and disabling 42-13

specifying objects that can display 42-14 sensor contact line pinning 42-14

sensor effects 45-2, 45-3 blur, noise, and gain 45-4 configuring 45-4

Sensor Enabled set data request 34-38 Sensor Settings page 45-4, 45-5

sensor signature 9-17, 65-29, 71-5

adding 71-12

affect of posture 23-5 modifying 39-9

Sensor Zoomset data request 34-39

separation-distance parameter 26-11

separation-tolerance parameter 26-11

separator, menu 79-2 server

terrain 52-7, 52-9

caching 61-3 cutting in site 57-14

session 3-6

ID 4-3, 5-8, 5-9

assigning 4-8 configuring B-4 setting at startup 5-10

joining at startup 4-16 message, configuring 4-16 starting and stopping 7-41

Session Options page 4-7, 7-10, 7-11, 7-12, 7-22,

7-41, 18-18, 18-19, 49-22, 78-10

sessionId parameter B-4 set

scripted 32-5

creating 32-26

Set Ammunition 34-8

Set Appearance 43-6

Set command, default 34-4 set data request 25-2

Activation 40-3

Active Sonar Mode 34-5 Aiming 34-7

Allow Crossing set 40-4 Altitude 26-25, 34-8

Ammunition Pacing/Tracking 34-9

Appearance 34-10

Armed 34-11

Arrowhead Style 40-4

Capabilities 34-11

Collision Avoidance Types 34-12 Color 40-4

Concealed 34-13

Contamination 34-13

Counter Measures Auto Launch 9-19, 34-13

Current Speed 34-14

Destroyed 34-14

Detonation Fuse Type 34-15


set data request (continued)

DI-Guy Characteristics 34-16 DI-Guy Hand Item 34-16 Disembarked 19-11, 34-17

Embarked 19-9, 34-17

Emitter 31-4, 31-21, 34-18

Engagement Results 34-19

Equipment Pacing/Tracking 34-20

Fill Style 40-5

Food, Water, Fuel, Oil, and Lubricant Pacing/Tracking 34-21

Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant 34-20

Force 34-21, 40-5

Formation 34-22

in plan 35-18

Heading 34-23

IFF 34-24

Invulnerable 34-25

Jam Targets 34-25

Lase Autonomous 9-16, 34-25

Laser Code 9-15, 9-16, 34-26

Line Width 40-5

Location 34-26

Navigation Preferences 34-28

Notify Level 34-28

tactical graphic 40-5

Ordered Speed 34-29

Pen Style 40-6

Percent Complete 34-29

Posture 34-30, 34-31

Radar mode 34-33

Reorganize 34-33

Resources 34-34

Resources Pacing/Tracking 34-34

Restore 34-35

Resupply Mode 34-35 Rules of Engagement 34-36 script 32-3

Sector of Responsibility 34-37 sending by radio 30-7

Sensor Aim 34-38 Sensor Enabled set 34-38 Sensor Zoom 34-39

Sonar Depth 34-40

Spot Reports 34-41

Superior 34-42

Supplying 34-42

Surrendered 34-42

Synchronize Laser Code 9-16, 34-43

set data request (continued) tactical graphics 40-2

Target 34-43

Tasked by Superior 26-12, 34-44

Tracer Use 34-44

Unit State 34-44

Weapons Pacing/Tracking 34-45 Set menu, icon 32-11

Set MOPP Level 34-27 Set Morale 34-27

Set Scenario End Time dialog box 7-35 Set Sensor Signatures dialog box 8-9 set statement 25-2

See also. set data request Set toolbar, adding to 79-6

setCheckpointMode function 33-14

setDeadReckoningAlgorithmToStaticOnPause

parameter B-5 setMainThreadToHighPriority parameter B-5 setting

altitude 16-14, 34-8

dialog box 16-15

manually 16-15

route 16-16

altitude for fixed-wing entity 26-25 ambient air temperature 11-5, 11-10

appearance 34-10

autonomous lasing 34-25

capabilities 34-11

collision avoidance types 34-12 color, unit bounding volume 25-11

combat engineering object percent complete 34-29

communication model 13-3

concealment 34-13

date 11-3

emitter 34-18

emitter volume radius 84-3 factory and default 4-21 formation 34-22

frame rate 5-4

heading 16-3, 34-23

manually 16-17

icons 4-21

IFF 34-24

laser code 34-26

loading 4-21

location 16-3, 34-26

LOD scale 43-10

MOPP level 34-27


setting (continued) morale 34-27

name 16-3

notification level 5-16, 34-28

entity 18-32

ordered speed 34-29

overlay 16-3

posture 34-31 precipitation

intensity 11-12

type 11-12

prop opacity 55-25

properties, object 16-3

resources 34-20

rules of engagement 34-36 saving 4-21

sector of responsibility 34-37 segment arc size 84-5 simulation object 34-4

parameters 34-4

to be destroyed 34-14

simulation speed with time management 7-24 sound volume 47-3

superior 34-42

support point 65-12

target 34-43 time of day 11-4 time zone 11-4

user 4-23

visibility 11-10

weather 11-8 settings

GUI, saving 78-3

GUI layout 5-5

property, default 65-54

scenario GUI 12-2

Simulation Object Editor, GUI layout 64-5 synchronizing 4-23

Settings menu 4-21

shader 1-15, 61-7

debugging 61-8 shadow

configuring 43-21

enabling and disabling 43-19 text, 2D label 18-16

Shadow Settings page 43-20, 43-21

shake, camera 49-27

shaking camera 49-27 shape terrain data 52-3

shapefile

buoys and beacons 57-23 converting S-57 to 62-7 exporting overlays to 38-6 importing to overlay 38-7 layer name 57-9

mapping to feature 55-11 sharing, resources 6-11

sheaf radius 31-27 ship

wake, configuring 83-14

shooter, laser 9-15

shooter-and-impact-point range 72-20

shooter-to-impact range 72-20

short name 65-7

Show Database Correlation Warning Dialogs 4-17 Show Function Profiler Overlay 6-8

Show Ground Truth For 9-6

Show Only Active Environmentals 39-19

Show Performance Statistics Overlay check box 6- 7

Show Session Terrain Change Prompts 4-17 Show Spot Reports from Viewpoint of Force 9-5,

9-6

Show Spot Reports Sent By 9-6 showHuds 77-7

showing

objects 37-6, 37-8

symbol decoration 18-15

vertex labels 37-9

showLines parameter 84-6

SHP, file 52-3

SIGGRP, attribute 57-31

SIGINT sensor 23-18 signal

interaction 42-20

sequence 57-31

signal group attribute 57-31 signal period attribute 57-31 signal_slot 69-24

signature, sensor 9-17, 71-5

signature propagator, configuring 71-9 signature-object-sensor 71-2

SIGPER, attribute 57-31

SIGSEQ attribute 57-31

SilverLining 1-19

license 1-19 simMgmtPduProcessLevel parameter B-5 SimObject class 33-4

simple driver 57-22


simple-radio-comm-model 15-7

Simthetiq 1-21

simulated world, navigating 49-3 simulation

closing 7-27

date 7-11

engine 3-2

objects 6-4

pausing 7-25

resuming 7-24

rewinding 7-25

running 7-24

automatically 7-36

speed, with time management 7-24 start mode B-5

starting 7-24

time 3-10, 4-17, 7-11

checkpointing in 7-32 evaluating in plan 35-13

Simulation Connections Configuration dialog box 4-32

Simulation Control Toolbar 4-11, 7-24, 7-25, 7-

26

Simulation Date/Time condition 35-14 simulation engine

closing 4-24

exiting 4-24

specifying 16-6, 16-8

simulation management message, configuring B-5 simulation model set 64-5

AggregateLevel.sms 23-2

configuration 7-9

default 7-11

creating 64-17

default 5-3

deleting entity 65-34

entity-level and aggregate-level 15-11 file 64-5

hostility file 9-10

multiple 7-8

new, creating 64-18

opening 64-16

platform file 69-16

specifying on command-line 5-11 simulation model set configuration, default 7-9 Simulation Model Sets parameter 7-6 simulation object

See also entity and unit

adding to, selection group 17-10 assigning plan to multiple 36-39

simulation object (continued) attaching observer to 50-7 attaching tactical graphic to 39-11 attribute, information 18-4

automatically attaching tactical graphic to 39- 11

behavior 15-10

centering observer on 49-26 changing

name 65-7

undoing changes 65-8

changing category 65-3

collision and obstacle avoidance 19-16 communication model 15-7

components 69-13

concepts 15-2

console, setting notification level 34-28 console message 18-31

saving 18-35

sending 36-33

viewing 18-33

copying 16-21

count 18-36

creating 16-3, 16-4, 16-8, 16-11, 19-3

from existing 65-33

in plan 36-33

multiple 21-5

creating multiple 21-2

creation, enabling and disabling 65-7 deleting 19-5

in plan 36-34 deleting in plan 36-33 destroyed 34-14

dragging 16-19

to new location 34-26 editing 19-5, 64-3

element definition 81-21

enumeration, published and matching 69-6 filtering attachment list 50-5

filtering list of 26-10

filtering using interest management 6-8 firing at target 9-13

heading 34-23

setting 16-17

hiding 9-2

hostility 9-10

icon 18-21

CID level and color 9-13 image 83-9

identifiers 15-3


simulation object (continued) information 18-3

multiple 18-9

inset view 51-2

label 15-5, 18-14

extended 18-17 list, spot report 9-9 local and remote 3-9 model 64-5

editing 65-3

reloading 65-27 move to location 27-16 name 18-9, 65-7

length restrictions 15-4

pasting 16-23

patrol between 27-24

patrol route 27-23

pinning intervisibility object to 46-10 placing 16-11

plan

issuing to 36-34

viewing 35-16

platform, updating 64-19

properties, specifying at creation 16-13 random creation of 16-25

remote

in task 26-3

plans 36-39

removing, from unit 24-8 resource, monitoring 18-29 resource at creation 19-4 restoring health and stores 34-35 selecting 17-4, 17-5

from Object Console Summary Panel 17-6 in Objects List Panel 17-6

setting

appearance 34-10

location 34-26

state and parameters 34-4 specifying resource 34-34

spot report, enabling or disabling 34-41 state 15-9, 34-4

systems

adding 65-30

editing 65-28

target detection 9-13

task 15-10

tasking by superior 34-44 tick rate, tuning 6-13 track history 42-5

simulation object (continued) trailing effect 42-3

unselecting 17-7

UUID 15-3

viewing in Navigation Lab 58-13 views of 17-2

waiting 30-10

ways to add to scenario 7-16 writing plan 36-3

zooming to extents 49-22 Simulation Object Editor 1-18, 64-3

command-line arguments 64-4

configuring DI-Guy character and appearance 65-16

embedded entity 19-13 force

adding 64-22

editing 64-23

removing 64-24

formation, bounding box 66-11 generating navigation data for entity 58-9 managing forces 64-22

navigating edited simulation objects 65-46 opening OPD Editor from 65-31 simulation object group 65-45

starting 19-19, 64-4 variable binding

adding 69-23

system definition file 69-25 simulation object group 7-16, 16-25

connection 65-46

creating 65-45

terrain 5-5

Simulation Object parameter 32-16 simulation object type

script availability 32-19

script validity 32-20

Simulation Object Type Mappings dialog box 82- 2

filtering element definition list 82-7 Simulation Object variable 35-15 Simulation Objects Palette 16-3, 16-4, 16-5

assigning or removing simulation object 65-7 Simulation Ocean Settings page 55-27 Simulation Selection Toolbar 4-11

Simulation Terrain parameter 7-5 Simulation Time condition 35-13 Simulation Time Scale Toolbar 4-11, 7-24

range, changing 7-25 Simulation Time Toolbar 4-11


simulationModelSet parameter B-5

Simulation-Model-Set-Files parameter 12-6

simulation-run-duration parameter 7-38

sink point 20-2

creating 20-4

SISO Enumerations Document 3-8

SISO Reference for Enumerations for Simulation Interoperability 69-4

site, cutting in 57-14

site ID 3-4, 5-8, 5-9, 5-11, 12-9

configuring B-5 specifying 5-11

at startup 5-15 siteId parameter B-5 sitting 34-31

situational awareness 48-10 size

region 6-9

sea spray 44-5

SpeedTree, randomizing 83-24

splash effect 44-5

water droplet 44-5

window 77-6

Size group box 65-10, 65-12 Skip Task, task 26-12 skipping task 26-10

skybox cube map 43-14 omitting clouds 43-14

Skybox Cube Map Regeneration Threshold 43-14 slider

visual quality, configuring 6-16 slot

adding 65-35, 65-36, 65-38

configuring 65-36, 65-38

embarkation 65-34, 73-6

exclusion 65-40

name 30-7, 65-34

type 30-7, 65-34

smallCompass, keyword 49-5 smoke

creating 28-13

plume 42-8

trail 42-3

smooth period 6-16

smoothing 6-16 SMS

migrating 64-13, 64-14

upgrading 64-14

vrfSim.opd 64-9

sms-filename parameter 7-38

snap to grid, formation 66-14 snapshot 7-30

automatic deletion 7-25

clearing list 7-34

creating 7-33

deleting 7-34

enabling periodic 7-34 rolling back to 7-25 saving as checkpoint 7-31

snow 11-5, 11-8

intensity 11-12

SO 4-31

SOEUILayoutSettings 64-5 SOG. See simulation object group soil type 61-13

configuring for GDB 53-2 mapped to roughness type 19-17 point and feature 53-16

soil-list parameter 19-17

solid line 39-17 sonar

active, mode 34-5 active and passive 9-17 depth 34-40

dipping 30-18

information 18-4

sonobuoy 30-17

thermocline 9-17, 11-22 Sonar Depth dialog box 34-40

Sonar Depth set data request 34-40 Sonar Dip task 30-18

sonobuoy, deploying 30-17

sound effects 47-2

adjusting volume 47-3

enabling 47-2

mapping, weapon fire and detonation 47-8 mapping to entities 47-4

range 47-3

sound file, mapping to entity 47-5 sound mapping

channel 47-8

detonation result 47-8 Space Follow mode 50-11 spacing, contour line 53-10 spawn burst 20-8

spawn event, scheduling 20-6 spawn interval 20-6, 20-8, 20-12

variance 20-6, 20-8, 20-12

spawn pattern 20-5

bursts 20-12


spawn pattern (continued) copying 20-14

creating 20-10

default 20-9

deleting 20-16

description 20-10

editing 20-15

name 20-10

new 20-10

scenario-specific 20-9

timing 20-11

Spawn Pattern Manager 20-2, 20-4, 20-10, 20-14,

20-15, 20-16

spawn point 20-2

creating 20-2

spawned, entity 20-2 specifying

application number 5-9

bounding volume 65-10

damage model 65-30

default default.sms 64-18

default SMS 64-18 entity to create 21-8 FED file 5-19

frame length 12-6 frame rate mode 12-6

HLA federation execution 5-17 language 5-4

log file 5-5

movement model 65-30

notification level 5-6

platform 65-8

point-to-point and multicast modes 5-20 port, at startup 5-20

resource 34-34

segment angle 84-5 simulation model set 5-11 site ID 5-11

terrain profile sampling frequency 54-3 unit target 34-32

specular

color 43-4

map 61-7

specular map 1-15

speed 18-10

gain 49-30

scaling 49-28

enabling and disabling 49-29 setting 34-29

specifying measurement unit 78-11

speed (continued)

tidal current 11-16, 11-18

wind 11-8, 11-9

speed scaling, mode 49-29

speed-to-rpm-factor parameter 9-18

SpeedTree 1-19, 57-7

configuring 83-22

license 1-21

LOD, zoom 5-7

model definition 81-12

scale, random 83-24

SpeedTree Randomization page 83-25 SpeedTree Settings page 83-23 speedTreeManager 57-7 spheroidSemiMajor parameter B-5 spheroidSemiMinor parameter B-5

splash effect 44-2

size 44-5

spot report 5-4, 9-2, 31-29, 31-30 affect on performance 6-12 custom viewpoint 9-6

decay rate 9-8

enabling and disabling 9-3

for simulation object 34-41 icon

changing 65-23

updating 65-21

label 9-9

role in target detection 9-15 tactical graphics, for 9-9 using in task 9-9

viewpoint 9-4, 9-5

Spot Report Options page 9-3, 9-5, 9-6, 9-8, 9-9,

34-41

Spot Reports dialog box 34-41 Spot Reports set data request 34-41 spotlight 43-2, 43-6

spray, enabling and disabling 44-6 squatting 34-31

squawk indicator 42-20

color 42-23

enabling and disabling 42-21 lifetime 42-22

standard beam 34-18

standard terrain damage 72-28

standard-power-type parameter 72-28

standard-terrain-damage-table 72-29

standard-terrain-damage-table block 72-28

standard-terrain-damage-type parameter 72-28

standing 34-31


starting

back-end 4-3

front-end 4-3

OPD Editor 70-2

scenario event 8-10

simulation 7-24

Simulation Object Editor 19-19, 64-4

VR-Forces 4-3 startInRunMode parameter B-5 startMinimized parameter B-5 Start/Resume message 7-41 startup

back-end minimize B-5 option 5-1

tutorial 4-9 state

sea 11-18

simulation object, information 18-4 update, sending 48-11

state repository 72-7, C-4 hierarchy 69-10, 69-12

statement

adding to plan 36-4 deleting 36-10 editing in plan 36-9

plan, drag and drop 36-40

state-repository parameter C-4, C-6

state-repository-min-tick-period parameter 6-14

state-repository-min-tick-period-variance parameter 6-

14

statistics

displaying 6-6

frame rate, log file B-3 status

combat engineering object 23-12 entity 18-29

navigation area 58-7

personnel, ammunition, weapons, and POL 18- 7

subtask 33-16

task 26-9, 33-16

statusUpdateHeartbeat parameter B-5 Stealth

control 36-35

observer mode 4-24

window 4-13

stencil bits 5-7

stencil buffer 6-14

step-function 72-22

stereo display, types of 77-20

Stop/Freeze message 7-41 stopping

movement 31-24

scenario event 8-12

subtask 33-16

task 26-10, 33-16

stopping-distance-factor parameter 73-4 stores, restoring simulation object 34-35 Stow Refueling Boom task 30-13

Strafe Ground Target dialog box 28-22 Strafe Ground Target task 28-21 strafing, target 28-7

streamed data performance 6-12

processing 57-7 streaming

beacon 57-28

buoys and beacons 57-23 navigation lights 57-29

terrain 52-9

street light 43-2, 43-6

strength 23-3 strong point

creating 31-21

improving 31-26 style

fill 39-17

line 39-17

pen 39-17 subcomponent C-4

classes 69-9

subgoal 3-15 submarine

lowering periscope 30-12 moving to depth 27-15 raising periscope 30-13

subnet mask 5-9, B-8 subnetMask parameter B-8 subordinate

adding to unit 66-5 disaggregated state 24-9

editing 66-7

in condition 36-22

information 18-7

order, changing 66-6 removing from unit 66-5 replacing 66-6

unit, aggregated state 24-9 Subordinates tab, unit 24-9 substitute-message-size parameter 13-3


subsurface entity

moving to depth 27-15 RPM 9-18

subsurface-entity-param parameter 69-12

subsurface-entity-param parameter C-8 subsurface-entity-state-repository 69-12 subtask

Lua 33-15

state

canceled 33-16

complete 33-16

running 33-16

status 33-16

stopping 33-16

sun, ray 43-12

sunbeam 43-12

sunrise-time parameter 71-13

sunset-time parameter 71-13 superior

setting 34-42

tasking simulation object 34-44 Superior dialog box 34-42 Superior set data request 34-42 super-type 69-5

supplies 23-13

information 18-7

providing 23-15

receiving 23-15

starting or stopping delivery 34-42 Supplies page 23-12

supplies parameter, editing 67-24 supply line 42-17

Supplying dialog box 34-42 Supplying set data request 34-42 support, technical lvi

support point, setting 65-12

suppression-degrades-sensor-performance-by parameter 26-35

suppression-detonation-insult parameter 26-34

suppression-detonation-range parameter 26-34

suppression-insult-level parameter 26-34

suppression-recovery-time parameter 26-34 suppressive fire

at location 26-32

at point, line, or area 26-32, 28-17 suppressSelfReflect parameter B-8 surface

characteristics 61-13

clamping to 19-20

damage specification 72-22, 72-26

surface (continued)

transparency 11-16, 11-18, 77-16 type, mapped to roughness type 19-17

surface entity buoyancy 44-7

RPM 9-18

wake 42-3

configuring 83-14

surface-entity-param parameter 69-12, C-8 surface-entity-state-repository 69-12

surfChar.map 61-13

surge depth 11-5, 11-16, 11-18 surrender

lifeform, testing 35-12

surrendered 35-12 Surrendered dialog box 34-42

Surrendered set data request 34-42 swell 1-14, 11-5, 11-16

sea 11-18

switch bead 85-8

switch node 83-18, 83-20

visual model 65-25 Switch Node States 65-25

SwitchStateMapper, feature 83-20 symbol, location of 2-4

symbol decoration, showing and hiding 18-15 Symbol Decoration Settings page 18-14, 18-15,

18-16

synchronization, vertical 6-19 Synchronize Laser Code dialog box 34-43

Synchronize Laser Code set data request 9-16, 34- 43

synchronized, ocean 5-6 synchronizing

back-ends 4-17

data and settings 4-23 laser codes 34-43

sysdef file. See system definition file system 69-17

active-radar-sensor 23-17

adding to simulation object 65-30 aggregate-comms-jammer 23-16

aggregate-radar-jammer 23-17

connection 69-18

damage 72-17, 72-34, 72-37

editing 65-31

properties 65-31

embedded entity 19-13

emissions-sensor 23-18

entity 65-28


system (continued) explosive device 72-16

marker in 3D model view 65-31 missile launcher 72-11

movement, properties 67-20

Naval Depth Charge Deployment 28-4 Naval Mine Deployment 28-5, 28-6 naval mine explosive device 72-16 removing 65-32

script 32-3

scripted task, creating 32-35 sensor 71-2

simulation object, editing 65-28 weapon 72-3

system definition, specifying scripted task in 32-21 system definition file 69-17, 72-3

applying new variable bindings 64-19 configuring connections 69-18

creating 69-17

sensor 71-4

variable binding 69-21

adding 69-22

addingto Simulation Object Editor 69-25 system scripted task, making available on Task

menu 32-35


T

-T command-line option 5-12

-t command-line option 60-5 tab

Create Object 16-11

overlay 38-4 table

damage 72-25

detection 9-13

Lua 33-15

taskParameters 33-17

tactical graphic 37-2, 82-2

active and inactive 39-19, 40-3 attaching to simulation object 39-11

automatically attaching to simulation object 39- 11

box, drawing 39-3

changing name 19-6

changing state with set data requests 40-2 color, changing 39-16

compared to combat engineering object 23-11 console, notification level 18-32

tactical graphic (continued)

creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,

39-2

editing 39-12

element definition 81-21 export to shapefile 38-6 extruded 39-4

force 40-5

HAT lines 37-10

hiding from Overlays tab 37-8 importing shapefile to 38-7 information 18-3

label 37-9

labels 37-3

loading 38-5

menu icon 65-53

model 65-56

moving, to different overlay 39-5 notify level 40-5

placing 16-11 property

default value 65-54

editing 65-55

keyword 65-55

setting at creation 16-13 publishing 39-7

saving 38-5

selecting 17-5

showing and hiding 37-6, 37-8, 39-19, 40-3

texture 65-56 vertex

adding 39-13

deleting 39-15

vertex color 39-17

volumetric 39-4

Tactical Graphic Active condition 35-14, 39-19,

40-3

Tactical Graphics Display Settings page 37-8, 37- 9, 37-10, 39-17, 41-3

Tactical Graphics Palette 16-4, 16-5 Tactical Graphics Settings page 39-19 tactical smoke, enabling or disabling 42-17 taillight 43-2, 43-6

takeoff, fixed-wing entity 26-26, 26-28

taking off 27-8 target

bomb 28-7

detecting 72-6

detection 9-13

spot reports 9-15


target (continued) firing at 9-13, 28-9

identifying with laser beam 9-15 setting 34-43

specifying using laser 28-12 strafe 28-7

strafing 28-21

unit, preferred 34-32 Target dialog box 34-43

target selection controller 72-6, 72-11, 72-13 Target set data request 34-43

targetFrameRate parameter B-5

targeting-capable parameter 34-18

targeting-control parameter 72-6

target-type parameter 72-8

task 26-3

Activate Jammer 31-4 adding to plan 36-4

Air-to-Ground Attack 31-4

Animated Movement 27-3 Anti-ship (Fixed Depth) 28-14 Arm Mine at Depth 28-3 articulated parts, moving 30-11 assigning to unit 26-11

Attack Aircraft with Guns 28-3 Attack By Fire 31-5

Attack with Anti-Air Missile 31-5 Attack with Anti-Ship Missile 31-5 Attack with Land-Attack Missile 31-6 Attack with Torpedo 31-6

Automatic Air Defense 31-6 background 31-31

background process 33-30

Biological Attack 31-7

Bomb Location 31-8

Breach Obstacles 31-9

by superior 34-44

C++ 32-3, 33-15

Change MOPP Level 31-10, 34-27

Change Posture 31-11, 34-30

Chemical Attack 31-11

Civilian Idle 29-2

Close Cargo Door 30-11 Close Door 29-2

Close Window 29-2 Come to Stop 27-4 concepts 25-1

concurrent 25-1, 26-5, 32-8, 32-18 configuring mutually exclusive 26-35

task (continued)

confirmation prompt, enabling or disabling 26- 6

Construct Abatis 31-12

Construct Anti-Tank Ditch 31-13 Construct Barbed Wire 31-14 Construct Barricade 31-14

Construct Berm 31-15 Construct Booby Trap 31-15 Construct Bridge 31-16 Construct Dry Gap 31-17 Construct Fortified Area 31-18 Construct Fortified Line 31-19 Construct Minefield 31-20 Construct Strong Point 31-21 Convoy Along 26-11, 27-4

Convoy To 26-11, 27-5

Create Pedestrians 29-3 Crowd Along Line 29-3 Crowd Around Location 29-4 Crowd Around Object 29-4 Crowd in Front of Entity 29-5 Deactivate Jammer 31-21 Deploy Refueling Boom 30-12 Deploy Sonobuoy 30-17

Deploy Sonobuoys Along Route 30-17 Destroy Bridge 31-22

Destroy Ditch 31-17, 31-22

Destroy Explosive 31-22

Destroy Fortification 31-23

Destroy Obstacle 31-23

DI-Guy Animation 29-5

Disembark 30-3

Disembark All 30-3

Disperse Crowd 29-5

Drop Naval Depth Charge 28-4

Drop Naval Depth Charge at Location 28-4 Drop Naval Mine 28-5

Drop Naval Mines Along Route 28-6 Embark 19-8, 30-4

escaping retask procedure 26-7 Execute Close Air Support 28-7 Explode Charge at Depth 28-9 FASCAM 31-24

Fast Rope Insertion 27-6

filtering simulation object list 26-10 Fire at Target 28-9

Fire Cruise Missile 28-10 Fire-for-Effect 28-11

Fixed Wing Land 26-29, 27-7


task (continued)

Fixed Wing Takeoff 26-28, 27-8 Flee From Entities 29-6

Fly Altitude 27-8

Fly Heading 27-9

Fly Heading and Altitude 27-10 Follow Entity 27-11

Generate Air Traffic From Flight Plans 27-12 Halt Movement 31-24

ID 33-15, 33-16

Improve Booby Trap 31-24 Improve Breach 31-25

Improve Bridge 31-25

Improve Ditch 31-17, 31-25

Improve Fortification 31-26

Improve Obstacle 31-26

independent 25-1

Indirect Fire 31-27

Land at Airport Near Location 27-12 Lase Target 9-16, 28-12

Launch Anti-Submarine Missile (Vertical) 28- 12

Launch Counter Measures 9-19 Launch Smoke 28-13

Lower Periscope 30-12

Lua 33-15

parameter 33-17 Move Along Route 27-13

Move Along Route Retrograde 31-28 Move Into Formation 27-14

Move to Altitude 27-15 Move to Depth 27-15 Move to Location 27-16

for plan 27-17

Move to Location (Plan Along Roads) 26-22, 27-18

Move to Location Retrograde 31-28 Move to Waypoint 27-20

Move to Waypoint (Plan Along Roads) 26-22, 27-21

Move to Waypoint Retrograde 31-28 movement, affect of aggregation state change

24-10

mutually exclusive 25-1, 26-5, 35-7

Nuclear Attack 31-29 Open Cargo Door 30-13 Open Door 29-6

Open Window 29-6

Orbit 27-23

parameters 26-7

task (continued)

Patrol Between 27-24

Patrol Route 27-23

Pattern Hold (Location) 27-24 Pattern Hold (Waypoint) 27-25 performing 15-9

Place IED 28-16

procedures, introduction 26-3 Protest Along Line 29-7 Protest Around Location 29-7

Provide Suppressive Fire 26-32, 28-17 Provide Suppressive Fire on Location 26-32,

28-18

Raise Periscope 30-13

reactive 21-10, 26-12, 30-19, 32-5, 33-8, 33-29

Release Bomb on Laser Spot 28-18 Release Bomb on Location 28-19 Release Bomb on Target 28-19 retask 26-3

Rotary Wing Airlift Cargo to Location 27-25 Rotary Wing Land 27-26

Rotary Wing Retrieve Cargo 27-26 Rotary Wing Unload Cargo 27-27 Sail Heading 27-27

scripted 32-3, 32-4

action category 26-36 adding to task toolbar 32-23 adding to toolbar 79-6

available by Behavior Set 32-21 execution flow 33-9

filtering list 32-31

Sector Search Operation 28-20, 30-15 Send Radio Set 30-7

Send Radio Task 30-9 Send Text Message 30-10 simulation object 15-10

Skip Task 26-12

skipping 26-10

Sonar Dip 30-18

spot report, using in 9-9 state

canceled 33-16

complete 33-16

running 33-16

status 18-4, 26-9, 33-16

stopping 26-10, 33-16

Stow Refueling Boom 30-13 Strafe Ground Target 28-21

Throw Grenade at Location 28-23, 28-24 toolbar, adding to 79-6


task (continued)

Turn to Heading 27-28 unit concepts 22-5

user 30-18

viewing current 35-16

visualizing 42-12

Wait 30-10

Wait Duration 30-11

Wait Elapsed 30-11

Wander 29-7 Wander In Area 29-8 who can execute 26-7

Task menu 32-4

extended name 32-12

icon 32-11

location for script 32-17

system scripted task, hiding 32-35 task visualization B-6

pinning 42-13

Tasked by Superior set data request 26-12, 34-44 using in plans 35-18

tasking, by superior 34-44

task-manager parameter C-5, C-7 taskParameters, table 33-17 taskVisualizationPublicationMode parameter B-6 TDB Tool 51-1

tearing off menu 78-8 technical support lvi teleporting observer 49-16

temperature, air 11-5, 11-10 template

earth file 61-5

unit 67-3

temporary directory, scenario 12-11 terminating, application 4-24 terrain

See also terrain database and terrain server

agility 1-12, 52-2 altitude point

changing color 53-6

deleting 53-5

inserting 53-5

analyzing 54-6

avoidance 26-31

building 55-5

caching earth files 1-18 coloring by elevation 53-4 composability 52-2

coordinates 53-16

creating 55-3

terrain (continued)

damage-by-power 72-28

databases provided 53-19

debugging 61-12

deleting cached 61-6 displaying raster image on 55-7 dragging with mouse 49-14 DTED support 55-4

dynamic 5-3, 59-3

damage 72-28

global dynamic terrain processor 7-7 earth file, debuggin 61-14

extracting props from 52-4 feature data, configuring 62-2 file caching 61-2

following 39-10

formats, supported 52-3 GDB, soil type 53-2 geocentric 52-6

intersector line 61-12

large 52-7

Little Pond 53-19

loading, from command line 5-7 Makland 53-19

MetaFlight designing 60-2

loading 56-5

processing 60-3

opening 52-7

orbiting, with mouse 49-15, 49-18 paged

flipping DDS textures 61-11 loading 5-10

preprocessing 56-6

page-in area 37-2, 56-6

paging 52-8

manually 56-6

MetaFlight 56-5

patch 52-3

adding to terrain 55-5 extracting props from 55-20

placement of new entities 19-3 profile. See terrain profile prop

adding 55-19

extracting 63-20

list 55-24

querying 62-3

San Luis Obispo 53-20 saving 55-4


terrain (continued) scale 53-17

server. See terrain server shape 52-3

simulation object group 5-5 soil type 53-16

streaming 52-9

tutorial 63-2

underwater 55-27

wireframe mode 53-10

Terrain Contents page 55-6, 55-12, 55-15, 55-16,

56-3, 61-15, 63-3, 63-21

terrain damage, standard 72-28 terrain database 1-12, 52-6

changing for a scenario 12-8 configuring B-6

path to B-3 loading 4-19

at startup 5-12 terrain draw area 53-18

Terrain Information Panel 53-14 terrain profile

concepts 54-2

configuring 54-3

displaying, line creation 39-6 line 37-2, 54-6

opening automatically 54-3

sampling frequency 54-3 terrain profile line 54-6 track history 42-7

vertex, showing 54-3

Terrain Profile Settings page 46-12 Terrain Profile window 54-2, 54-3

intervisibility line 46-12

terrain server 52-7, 52-9, 56-2

adding 56-4

caching data 61-3

connecting through proxy 56-5 cutting in site 57-14

mask, adding 57-14 Terrain Settings dialog box

Add Props page 55-22, 63-9, 63-13 Earth Layers page 53-12

Edit Existing Props page 55-24, 55-25, 55-26,

63-23

Extract Ocean page 55-15 Extract Props page 55-20, 63-21 Navigation Areas page 58-3

Raster Maps page 55-7, 55-10, 63-5 Simulation Ocean Settings page 55-27

Terrain Settings dialog box (continued) SpeedTree Randomization page 83-25

Terrain Contents page 55-6, 55-12, 55-15, 55-

16, 56-3, 61-15, 63-3, 63-21

Visible Surfaces page 53-3

terrain-check parameter 26-31

Terrain-Database parameter 12-5

terrainDatabase parameter B-6

terrain-following, fixed-wing entity 26-26 TerraPage file 52-3

TerrraPage file 56-6

testing, amount of resources 35-13 Tether Location Track mode 50-13 Tether mode 49-8, 49-26, 50-7, 50-12

Tether Track mode 50-13 text

creating 39-5

in title bar 78-10 object, resizing 39-15

sending 30-10

shadow 18-16

text editor 32-4

scripts, specifying 32-37

texture 83-26

atlas, buoy and beacon 57-27 compression, enabling and disabling 61-6 coordinate system for image 55-9

data, converting 61-13

DDS 61-10

flipping, paged terrain 61-11

height, ocean planar reflection 43-10 map 1-15, 61-7

mapping to model 83-19 model 83-19

sharing 6-11

size, ocean height map 55-17, 55-18 skinning

metafile 83-20

model 83-19

tactical graphic 65-56 tiled and virtual 60-4 water 55-13

width, ocean planar reflection 43-10 texture atlas 83-19

thermocline, sonar 9-17, 11-22 thickness, contour line 53-10 this, Lua object 33-4

threat ring 18-24 threshold

data updates B-3


threshold (continued) DIS heartbeat B-7 object timeout B-7

Throw Grenade at Location dialog box 28-23 Throw Grenade at Location task 28-23, 28-24 Throw Grenade at Target dialog box 28-24 tick

rate, tuning 6-13 tidal current

direction 11-18

speed 11-18

speed and direction 11-16 tidal stream, wake 11-19, 83-17

TIFF 52-4

tiled texture 60-4 time

evaluating in plan 35-13 scenario

end 7-35

ending 7-7

setting 11-2, 11-4

setting in new scenario 7-7 simulation 3-10, 7-11

default 7-12

zone 7-11, 11-4

setting 11-4

time constrained 4-17 time management

concepts 4-17

configuring 4-18

enabling 4-18

for back-end 4-19, 5-19

RTI requirements 4-18 setting simulation speed 7-24

Time Multiplier parameter 7-6 Time Multiplier toolbar 12-5 time of day 3-10, 11-2

illumination 71-12

time regulating 4-17

time stamp 5-7, 5-12

time stamp order, configuring B-7 time stamp ordered message 4-18 time zone 11-2

timed fuse 34-15

time-multiplier parameter 12-5 timeout

DIS 5-10

interval 5-8 object B-7

timestamp 5-3, 5-7

timing, spawn pattern 20-11 tire track 42-3

title bar

text, adding 78-10 To Echelon Level 25-7 toolbar

adding task or set 79-6 Attachments 50-2

button 4-11

configuring 79-2, 79-6

Display Settings 18-15 displaying and hiding 78-3 element 79-6

Environment Settings 11-3, 11-4

icon, setting 79-7

locking 79-7

Map Scale 53-17

Objects 17-6, 19-7, 19-10, 24-6, 25-4

Quick Launch 8-10

Scenario 7-33

Scenario Event 8-2

Simulation Control 7-24, 7-25, 7-26 Simulation Objects Palette 16-5 Simulation Time Scale 7-24

task, adding script 32-23 toolbarrow, element 79-6 topmark, buoy and beacon 57-31 topmark_attr_map.csv 57-31

topological model 3-12

TOPSHP attribute 57-30, 57-31

torpedo 31-6

anti-submarine 28-12

launching 28-14

tracer 34-44, 42-8

configuring 72-8

Tracer Use dialog box 34-44 Tracer Use set data request 34-44 tracer-type parameter 72-8

track, radar mode 34-33 track history

configuring 42-6

displaying 42-5

enabling and disabling for all simulation objects 42-5

length 42-6

terrain profile 42-7

Track History Settings page 42-7 Track mode 49-8, 50-7, 50-14 tracking

ammunition 34-9


tracking (continued) entity, resources 18-29

equipment 34-20

resource 34-34

weapon 34-45

tracking beam 34-18 traffic

generating 20-2

spawn pattern 20-5

trail, model 42-4

trailing effects 42-3, 82-2 enabling and disabling 42-4 model 42-4

simulation object 42-3

trajectory, smoothing 6-16 trajectory history. See track history transform, multiple 62-5

transforming, attribute 62-4 transient intervisibility

displaying 46-6

object 46-5 transition time

posture, editing 67-21 translating, GUI text 2-10 translation 67-26

transmitter, publishing radio 74-4 transparency 83-26

prop, setting 55-25

surface 11-5, 11-16, 11-18, 77-16

transponder, IFF 34-24

trap, creating 31-15

Travel, posture 23-4

tread track 42-3 tree

prop type 55-26

setting avoidance 34-12

SpeedTree 83-22 triangle, vertex label 37-9 triangle icon 18-35

trigger 35-7

cleaning up unused 36-9 deciding order in plan 35-17 name 35-8

reactive task 26-12

registering 36-8

registration 35-8

taskless 35-17

unregister 36-9 Triton Ocean SDK 1-20

TrueType font, 2D icon 83-4

tuning

components 6-13

network performance 6-15 performance

component 6-13

network interface 6-14

state repository 6-14

visual performance 6-15

turn rate 27-9, 27-10

Turn to Heading dialog box 27-28 Turn to Heading task 27-28 turret, attaching to 50-4

tutorial

composing terrain 63-2

extract props 63-20

starting VR-Forces 4-9

TXP file 52-3 type

adding 67-26

prop 55-26

slot 30-7, 65-34

type attribute 83-6


U

-u command-line option 60-5 UI file 69-23

variable binding, adding 69-24 unconstrained 4-17

underFireDistance parameter 34-36

underFireTime parameter 34-36

underwater, visibility 11-16, 11-18 Underwater Acoustics PDU 9-17 undo, ellipse rotation 39-16 undocking, panel 78-2

undoing

category changes 64-21

simulation object edits in Simulation Object Editor 65-8

unexploded ordnance, destroying 31-22 unique

buoy 57-26

ID 15-3

unit C-8

activity 34-6

adding entity to 24-7

adding simulation object to 34-42 aggregated state 24-9

aggregate-level 24-4

aggregated 31-5


unit (continued)

ammunition, weapons, equipment 67-5, 67-8

artillery 31-27

assigning tasks 26-11

attrition 23-10

from combat engineering object 23-10 bounding box, Simulation Object Editor 66-11 bounding volume, color 25-11

changing state manually 24-12 closing formation 22-5

collapsing 25-3 collapsing to root 25-3 convoy 27-4, 27-5

behavior 26-11

count of 18-36

creating 24-2, 66-4

preconfigured 24-5

crowd, creating 21-3

deleting 24-13

disaggregated and aggregated 22-2 disaggregated state 24-9

disaggregation area 24-12

display 78-11 displaying by level 25-4

displaying ghosted icons 25-6 echelon ID 22-3

editing 66-4

embark task 30-4

entity, individual tasks and plans 24-11 entity-level 22-2

expanded and collapsed 22-2 expanding 25-3

expanding all 25-3

expanding and collapsing 25-2 footprint 23-4

formation 22-4, 34-22, 73-2

adding 66-9

automatic layout 66-13

copying 66-12

default 66-10

editing 66-8

manual layout 66-13

removing 66-10

renaming 66-10 snap to grid 66-14

information 18-3, 18-7

introduction 24-8

measurement 78-11

movement 22-4, 23-6

affected by combat engineering objects 23-9

unit (continued)

moving to formation 27-14 new 67-3

organization concepts 22-3

parameter type 69-25

posture 23-4

preconfigured 24-5

removing simulation object from 24-8, 34-42

reorganizing 22-4, 22-5, 34-33

restoring 24-10, 34-35

restricting movement 62-9

sector 18-24, 23-4

selecting 24-6, 25-2

sensor 23-8

setting formation in plan 35-18 specifying as Aggregate As option 66-3 state

affect on combat 24-10

affect on movement task 24-10 affect on resource tracking 24-10 at creation 24-6

changing at runtime 24-10 initiating change 24-11

setting 34-44 showing in GUI 24-9

subordinate adding 66-5

changing order 66-6

editing 66-7

in condition 36-22

removing 66-5

replacing 66-6

target, preferred 34-32

task behavior 22-5

template 67-3

writing plan for 24-12, 36-39

Unit Display Settings page 25-7, 25-10, 25-11,

42-10, 42-17

Unit State dialog box 34-44 Unit State set data request 34-44

Universal Transverse Mercator 52-6 unloading

cargo 27-27

entities from entities 19-7 unlocking, overlay 38-3 unpublishing, tactical graphics 39-7 unregistering, trigger 36-9 unselecting

object 17-7

simulation object 17-7


unused range 72-20 update

frequency of B-3 messages 48-11

rate, intervisibility 46-9

Update_EW_Degradation, script 23-17

updater 83-10

AOA 83-12

attribute 83-10

FeetAGL 83-12

FeetMSL 83-12

FeetPerMinute 83-12

Headlight 83-13

KilometersPerHour 83-12

KnotsPerHour 83-12

MilesPerHour 83-12

Pitch 83-12

Roll 83-13

Value 83-13

Yaw 83-13

updating

platforms 64-19

visual models 65-27

window layout 78-6 upgrades lvi upgrading, SMS 64-14

Use Extracted Geometry 55-20 useAbsoluteTimeStamps parameter B-7, B-8 use-actual-message-size parameter 13-3 useAdvisories parameter B-7

useAsyncIO parameter B-8 useCustomMapDatum parameter B-6 Used By Countries list 65-9

clearing 65-9

USE-DEFAULT keyword 12-10

useDIGuy parameter B-6 useDrawControlForTaskVisualizations parameter B-6 useIpv6 parameter B-8

use-logger-control parameter 7-38 user

settings 4-23

task 30-18

user data, specifying directory 5-7 User Task dialog box 30-18

user-defined, formation 73-4 using

Boundary Generation Tool 57-15 navigation data 58-8

UTM 52-6

coordinate system 49-7

UTM (continued) database 7-3

UUID 15-3

scheme 5-6

simulation object 15-3

UV, coordinates 55-9

UV offset 83-21

UvAtlasMapper, feature 83-20


V

-v command-line option 5-7, 5-12, 5-14, 60-5

Value updater 83-13

vapor trail 42-3 variable

Created Object 35-15

global, saving 33-14

plan 35-15

Simulation Object 35-15

tick rate 6-13

variable binding 69-21

adding to platform file or system definition file 69-22

adding to Simulation Object Editor 69-21 applying changes 64-19

platform file 69-21

Simulation Object Editor, adding new 69-23 variable frame mode 6-17

variable-frame keyword 12-6

variable-frame run-to-complete 3-11, 12-6

variance, spawn interval 20-6, 20-8 varying, heartbeat B-7

vector

geocentric 33-20

Lua 33-18, 33-20

network 26-22 vector feature

configuring avoidance of 73-5 list 53-14

Vector3D class 33-18

VectorGeoc3D class 33-20

VectorOffset3D class 33-20

vehicle, model 1-7 velocity

displaying 18-11

specifying measurement unit 78-11

vel-to-align-actual parameter 26-32

vel-to-align-desired parameter 26-32 version

displaying 5-7


version (continued) plug-in, checking 5-3

RPR FOM 5-8, 5-13, B-7

version parameter, scenario file 12-6 vertex

adding 39-13

altitude, displaying 37-10

deleting 39-15

editing 39-14

line, terrain profile 54-3 showing and hiding 37-9 tactical graphic, color 39-17

video, adding to scenario event 8-5 video card, processor speed 6-4 view

clearing list 49-32

constraint 49-28

default 49-32

deleting 49-32

dragging with mouse 49-15 floor 49-28

inset 51-2

loading saved 49-33

navigating 49-3

observer, transitioning between 49-32 recalling 49-30

restoring 49-31

saved, scenario 12-2 saved with scenario 6-1

saving 49-30, 49-31, 49-33

zooming 49-18

2D 49-20

3D 49-19

view constraint, disabling 19-4 view control, sending in plan 36-35 view control message 49-34

enabling processing of message 49-34 script 49-34

view mode Absolute 50-7

Follow 50-8

Mimic 50-9

Mimic Location Track 50-10 Mimic Track 50-10

Space Follow 50-11

Tether 50-12

Tether Location Track 50-13 Tether Track 50-13

Track 50-14

viewing

current task 35-16 list of props 55-24 Logger files 7-41

obstructed terrain in terrain profile 46-12 other MAK 3D GUI viewers 48-12

plan 35-16

plug-in, data 4-37

terrain polygons 53-18 viewpoint

spot report 9-4, 9-5

custom 9-6

viewport 77-7

changing 77-15

virtual texture 60-4

Virtual Texture Datasets 60-3 visibility 11-8, 11-10

modifier 23-10

observer 11-5

underwater 11-5, 11-16, 11-18

water 77-16

visible surface, configuring 53-2 Visible Surfaces page 53-3

Visit Interest Points reactive task 21-10 visual definition 81-4, 81-21, 81-25

adding 81-26

attribute 81-27

adding 81-30

editing 81-27, 81-29

Entity Image Symbol 83-2, 83-4, 83-9 Military Symbol Icon 83-2

schema 81-4 visual model

adding 65-24

details 65-25

editing 65-19

exporting 65-27

importing 65-26

pruning 65-26

refreshing 65-27

tactical graphic 65-56

Visual Model Editors dialog box 81-9 visual quality 55-17

visual quality slider, configuring 6-16 visual sensor 71-12

visualization, task B-6 visualizer 81-21

visualizing, tasks 42-12 volume

sound, adjusting 47-3


volumetric, tactical graphic 39-4

vrf class 33-4

vrf-base-object-param parameter 69-26, C-3 vrf-base-object-param parameter type C-7 vrfGui 3-2

vrfGui.log file 4-38 vrfLauncher

combined mode 5-15

special command-line arguments 5-15 vrf-moving-object-state-repository 69-12

vrfMsgDump 1-18

vrf-object-param parameter C-7

vrf-object-param parameter 69-12

vrf-object-state-repository 69-12 VR-Forces

entity or object 3-9 Launcher 4-3

starting 4-3

window 4-11, 4-20

VR-Forces Objects Panel 50-2 VR-Forces window 7-7

vrf-overlay-object-state-repository 69-12 vrfSim

log file 5-11

running as daemon B-2

vrfSim 3-2

daemon, starting as 5-10 vrfsim

enabled 57-22

layer 62-2 VRFSIM_OSGEARTH_CACHE_PATH

environment variable 61-3

vrfsim: 57-21

vrfSim.log file 4-38 vrfSim.mtl file B-2 vrfSim.opd

remote-configurations block 76-3 required in every SMS 64-9

vrfSimSettings.xml file 6-15

vrfutil, functions 33-6

VR-Vantage, view control 36-35 VR-Vantage Control Toolkit 49-34 VSync 5-4, 6-19

VTDS 60-3

vulnerability 23-3

modifier 23-9


W

-w command-line option 60-6

wading 34-31

Wait Duration dialog box 30-11 Wait Duration task 30-11

Wait Elapsed dialog box 30-11 Wait Elapsed task 30-11

Wait task 30-10

Wait Until 35-9

Wait Until Expression dialog box 36-6 wake 1-14, 1-20, 42-3

enabling and disabling 44-6 model definition 11-19

ship, configuring 83-14

tidal stream 11-19, 83-17

wakeLength parameter 11-19

walking 34-31

wall, not walking through 49-28 wall-clock time 4-18

wander, crowd 29-8 Wander In Area task 29-8 Wander task 29-7

warfare, electronic 23-16, 23-17, 23-18 warfare model, aggregate 23-2

warhead actuator 72-17

warhead parameter 72-8

warhead parameter 72-18

warhead-detonation-actuator 72-16

warning, icon 18-35 warning message B-4 water

pacing and tracking 34-21 splash 44-2

texture 55-13

extracting 55-15

visibility 77-16 water droplet, size 44-5 wave

breaking 11-21

choppiness 11-16

effect 44-2

waypoint 37-2, 37-4

altitude, displaying 37-10 civilian visit point 21-9 ordering entity to 27-20 patrolling between 27-24

weapon

anti-air 31-6

fire, sound mapping 47-8 laser guided 28-12

pacing and tracking 34-45 status 18-7


weapon (continued) system 65-28, 65-29

system definition file 69-17 unit 67-5, 67-8

weapon interface 72-6

weapon system 72-3

bomb-bay 72-17

indirect fire 72-14

weapong system 72-4

weapon-interface 72-11, 72-13

Weapons Pacing/Tracking dialog box 34-45 Weapons Pacing/Tracking set data request 34-45 weather 11-5

global 7-7

setting 11-8

Weather dialog box 11-15

Weather page 11-6, 11-7, 11-8, 11-9, 11-10, 11-

11, 11-12, 11-17, 77-16

weather zone 11-13

priority 11-13

When statement 35-4, 35-7

building 36-11

While Expression dialog box 36-6 While statement 35-4, 35-9

WidgetTheme, attribute 83-6

width

changing for line 39-17 sensor contact line 42-15

wildcard 69-7

wind 1-14

direction 11-5

moving flags and windsocks 83-18 offset 10-2

speed 11-5

speed and direction 11-8, 11-9

WindDirPart 83-18 window

Add Visualizer Definition Attribute 81-30 adding 77-2

attributes, editing 77-6

channel, adding 77-4

closing 29-2

Event 8-10, 8-12

location, changing 77-6

Multiple Object Information 18-9 new 4-13

observer 48-6

opening 29-6

printing 4-13

property 77-6

window (continued) removing 77-5

secondary 4-13

selecting simulation objects in 17-5 size, changing 77-6

specifying 5-4

Terrain Profile 54-2

types 77-2 window layout

changes, saving 78-6

choosing 78-5

creating 78-4 default

clearing 78-6

setting 78-5

deleting 78-7

restoring factory 78-7

reverting 78-6

updating 78-6

Window Layout Manager dialog box 78-4 Window Name attribute 77-6

Window Type attribute 77-6 Windows, installing on 2-2 windsock, movement in wind 83-18 WindSpeed parameter 83-18

WindState parameter 83-18

WindSwitchPart 83-18

wireframe mode 53-10

world coordinates 49-3 writing

entity plan 36-3

global plan 36-26 plan

for multiple simulation objects 36-39 for unit 24-12

plans, remote entities 36-39

WRM Entity Model Specification 85-1, 85-9


X-Y-Z

-x command-line option 5-8, 5-9, 5-13, 5-17, 5-

21, 60-6

XML 57-3

include files 57-5

RTI configuration file 2-9 XML file

plug-in 4-34

deleting 4-37

XR mode 48-10

XR scaling 19-23


xtr file 12-10

yaw 49-3

Yaw updater 83-13

yellow icon 9-13

yellow triangle icon 18-35 Z Far 77-7

Z Near 77-7

Z-fighting 5-7, 50-6, 55-13, 77-10, 77-16

zone

time 7-11

weather 11-13 zoom

scale factor, LOD 49-20 scenario, on load 49-22 SpeedTree LOD 5-7

switching from 3D to 2D 48-2 to entity extents 49-22

to extents 49-22 zooming

observer 49-18

2D 49-20

3D 49-19

performance 49-21

sensors 34-39

VR-Forces Quick Reference Card


image

Table QR-1: vrfSim Command-Line Options


Option Description

Option Description

(-a | --appNumber) application_number Specifies the application number.

--additionalSystemScriptsDirectory directory Specifies a directory where VR-Forces will look for system scripts

when it populates the Scripted Task dialog box script list.

--appDataDir directory Specifies the location of the appData directory.

--appIdRange lower-upper Specifies a range of application IDs that represent objects generated by VR-Forces.

(-B | --batchScenarioFileName) batch_file Runs the specified batch file. (For use with one back-end only.)

(-c | --frontEndPID) PID The process ID for the front-end when running in combined mode.

--countryCodesMappingFile file_name Specifies an alternative file that maps country codes to country

names and DIS enumeration values.

(-d | --settingsFile) file_name Specifies a configuration file to load instead of vrfSimSettings.xml.

--daemon Starts that back-end as a daemon process (Linux only).

--dataDir directory Specifies the data directory for the back-end.

--diGuyAnimationsFile file_name Specifies an additional configuration file for DI-Guy animations.

--diGuyCharacterDataFile file_name Specifies an additional configuration file for DI-Guy character data.

--disableCallbackQueue Disables all main thread parallel algorithms.

--disableParallelTick Execute all tick code serially.

--doNotLoadVrfPlugins Do not load any VR-Forces plug-ins from the ./plugins directory.

--enableChannel channel Enables a specific channel for the channel-specific output, even if it is disabled in channelSettings.mtl.

--fileNotifyLevel level Notify level in log file to use.

--fullyLoadTerrain For paged terrains, load all pages.

(-h | --help) Displays help information in a console window.

--hostAddressString address The IP address of the host computer. (Device Address in Launcher.)

(-i | --sessionId) session_ID Specifies a session ID.

(-L | --scenarioFileName) Loads the specified scenario. Mutually exclusive with the -T option.

"scenario_pathname"

--loadPlugin plugin_file Specifies one or more plug-ins to load. (Accepted multiple times.)

--logFileName filename Log file to use.

--logFrameRateStatistics Specifies that the back-end should log frame rate statistics.

--msdlSIDCMappingFile file_name Specifies an alternative file for mapping SIDC codes to DIS enumera-

tions.

(-n | --notifyLevel) notification_level Sets the level for messages written to the console or the VR-Forces log file (vrf.log).

--noRtiCompilerCheck Disable RTI Compiler version check.

--nonVrfObjectsUUIDScheme scheme Sets the UUID scheme for non VR-Forces objects. Values are

entity-identifier, global-identifier, marking-text.

image

image

Table QR-1: vrfSim Command-Line Options


Option Description

Option Description

--numCallbackThreads threads Number of threads in the callback queue.

--outputLogFile file_name The file to use to write out application output.

(-q | --doNotUseConsole) Specifies that all vrfSim output go to the log file.

(-r | --startInRunMode) Starts the back-end in run mode.

(-s | --siteId) site_id Specifies the site ID.

--setMainThreadToHighPriority If enabled sets the VR-Forces main thread to high priority. Windows

only.

--simulationModelSet sms Specifies the simulation model set.

--startMinimized Minimizes the vrfSim console at startup.

(-T | --terrainDatabase) terrain_database Specifies a terrain database to load in the back-end. Mutually exclu-

sive with the -L option.

--targetFrameRate rate Specifies the frame rate above which vrfSim will yield CPU time.

--useAbsoluteTimeStamps Use absolute time stamps instead of relative time stamps.

--userDataDir directory Specifies the user data directory for the back-end.

--disableParallelPreprocess Disables parallel processing for components that use it.

(-v | --version) version Displays version information.

--waitQueue Turn off main thread participation in parallel algorithms.

image

(-- | --ignore_rest) Ignore all command-line options that are listed after this argument.

HLA Only

HLA Only

(-f | --fomMapperLib) libname FOM Mapper library name.

(-F | --fedFileName) fedfile_name FED file name.

--fomMapperInitData data FOM Mapper initialization data.

--fomModules module Specifies an HLA Evolved FOM module. Can be used multiple times.

--ignoreAdvisories Enables or disables HLA advisory messages. Default: true.

--mimModule Specifies an HLA Evolved MIM module.

(-N | --federateName) federate_name Specifies a unique name that can be assigned to the federate.

Default: VR-Forces. (HLA Evolved only)

(-p | --federateType) type Distinguish different categories of federates.

--rprFomRevision RPR FOM revision for RPR FOM 2.0, draft 17.

--rprFomVersion version_number RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006, 2.0014, 2.0017 or

2.0)

--localSettingsDesignator designator Specifies a string that is passed to the RTI during federate connect

when using HLA Evolved.

--timeManagement Enables time management for the back-end.

image

(-x | --execName) exec_name Execution name. Default: VR-Link.

DIS Only

DIS Only

(-A | --destAddrString) address Destination address.

--defaultObjectTimeout timeout Specifies the timeout interval for objects.

image

image

Table QR-1: vrfSim Command-Line Options


Option Description

Option Description

--deviceAddress address Specifies the address of the network card to use for UDP traffic.

--disVersion The DIS version. Default: 5.

--mcastTtl Specifies the multicast time-to-live. Default: -1.

(-S | --multicastAddresses) address1 ... Specifies one or more multicast addresses.

addressn

(-P | --disPort) port DIS port.

--recvBufferSize size Receive buffer size.

--sendBufferSize size Send buffer size. Default: -1.

--subnetMask mask Specifies the subnet mask.

--suppressSelfReflect Represses self reflection of the DIS exercise connection.

--useAsyncIO Use asynchronous I/O. Default: False.

--useIpv6 Specifies that the DIS exercise connection use IPV6.

(-x | --exerciseId) ID Exercise ID.

image


image

Table QR-2: vrfGui Command-Line Options


Option Description

Option Description

(-- | --ignore_rest) Ignore all command-line options after this one.

--alphaBits bits Sets the number of alpha bits (0, 8).

--antiAliasing level Set the anti-aliasing level (0, 2, 4, 8, or 16). Default: 4.

--appDataDir directory Specifies the location of application data.

--appIdRange range Application ID range of VR-Forces back-ends.

(-c | --showConsole) Display a console window.

(-C | --autoConnect) {filename | Automatically connect to the network using the specified connector.

connector_name}

--dataDir directory Specifies the location of the data directory .

--defaultSimulationModelSet sms The simulation model set to use as the default when starting up the GUI.

--depthBits bits Sets the depth of graphics to 24 bits or 32 bits. Default: 24.

--dis Use the DIS protocol and enable DIS-specific options.

--disableDynamicTerrain Disables the dynamic terrain engine.

--discoveredModelPreloadFileName

filename

Specifies a file to which the list of models discovered during a session that were not preloaded is written.

--dispSetting filename Specifies the display configuration to load.

--doNotCheckPluginVersions Do not check the version in a plug-in to make sure it can load in VR-

Forces.

--doNotLoadVrfPlugins Prevents loading of plug-ins in the ./plugins directory.

--enableVSync Turns on VSync.

--entDispSetting filename Specifies the entity display setting to load.

--entityDefsDir directory Loads the .hier and .leaf files in the specified directory.

image

--envSetting filename Specifies the environment configuration file to load.

(-E | --entTypeMap) filename Load the specified entity type mapping file. The file extension determines

the type of mapping.

--factoryRootDir Set the root directory used to restore settings to factory defaults.

--fileTransporterReceivePort port Port for the file transporter.

--forceTextShaping Force all text to use HarfBuzz shaping.

--fowPerspective force Shows the ground truth and spot reports perspective for the specified

force.

--fullScreen Start in full screen mode.

--frameRate rate Specifies a fixed frame rate for rendering. If 0, it is variable.

(-G | --locale) language Specifies the locale (for localization).

--gui filename Specify GUI configuration file to load.

(-h | --help) Displays command-line usage information.

--highestPriority Changes application and the main render thread to the highest available priority.

--hla13 Use HLA 1.3 and enable HLA-specific options.

--hla1516 Use HLA 1516 protocol and enable HLA-specific options.

--hla1516e Use HLA Evolved protocol and enable HLA-specific options.

(-I | --unbatchedRendering) Disables instance rendering.

(-K | --disableKDTrees) Disable creation of KD trees for intersections.

(-l | --logFileName) filename Specifies the log file name.

--layoutSettingsFile filename Specifies the GUI layout settings file to use. filename specifies the base

filename. It is prefixed with default_ and the extension .uisx is added.

--loadPlugin filename Specifies plug-ins to load. Accepted multiple times.

--loadSimulationObjectGroup group Creates a new scenario on the simulation object group editing terrain and

creates an instance of the simulation object group on that terrain.

(-L | --loadObservers) filename Loads the saved observers in the specified file. Can be used multiple

times.

--mainScreenNum num Specifies the display that the main window should use.

--mergeEntityTypeMap {directory |

filename}

Merges all entity type mapping files (*.metx) in a directory or individual entity type mapping files. Can be used multiple times.

--mergeHierarchyEntityDef filename Merges the specified .hier file into the default hierarchy. Merging is addi-

tive.

--mergeHierarchyTacticalGraphicsDef

filename

Merges the specified .hier file into the default hierarchy. Merging is addi- tive.

--mergeHierarchyUnitDef filename Merges the specified .hier file into the default hierarchy. Merging is addi-

tive.

--mergeLeafEntityDef filename Merges the specified leaf file into the default entity element definitions.

--mergeLeafTacticalGraphicsDef

filename

Merges the specified leaf file into the default tactical graphics element definitions.

--mergeLeafUnitDef filename Merges the specified leaf file into the default unit element definitions.

--mergeModelDefs {directory |

filename}

Merges all model definition files (*.ommx) in the specified directory or individual model definition files. Can be used multiple times.


image

image

Table QR-2: vrfGui Command-Line Options


Option Description

Option Description

--mergeTacticalGraphicsTypeMap

{directory | filename}


--mergeUnitTypeMap {directory |

filename}

Merges all tactical graphics type mapping files (*.metx) in a directory or individual tactical graphics type mapping files. Can be used multiple times.

Merges all unit type mapping files (*.metx) in a directory or individual unit type mapping files. Can be used multiple times.

--modelPreloadFileName filename Specifies a file that has a list of models to preload.

(-n | --notifyLevel) notify_level Specifies the notification level for application messages. Range: 0-4.

--noAppDataEntityDefs Do not load the entity element definitions in ./appData/definitions.

--noAppDataTacticalGraphicsDefs Do not load the tactical graphics element definitions in ./appData/defini-

tions.

--noAppDataUnitDefs Do not load the unit element definitions in ./appData/definitions.

--noAppDataEntityTypeMap Do not load entity type mappings in ./appData/settings/<application>.

--noAppDataModelDefs Do not load model definitions in ./appData/definitions.

--noAppDataTacticalGraphicsTypeMap Do not load tactical graphics type mappings in ./appData/settings/<appli-

cation>.

--noAppDataEntityTypeMap Do not load unit type mappings in ./appData/settings/<application>.

--nonVrfObjectsUUIDScheme scheme Sets the UUID scheme for non VR-Forces objects. Values are entity-iden-

tifier, global-identifier, marking-text. Default: entity-identifier.

(-O | --hasNTPSync) Enables synchronized ocean between different display engines. System

clocks must be synchronized.

--plugin filename Load the specified plug-in. Can be used multiple times.

--pseudoFullScreen Use pseudo full screen for full screen mode.

--pvd Start the VR-Forces front-end with only 2D modes available.

(-S | --suppressHatIntersectOnAttach) Suppress the periodic HAT intersection when attached.

--scenarioFile filename Specifies a scenario to load.

--stealth Start the VR-Forces front-end with only 3D modes available.

--stencilBits bits Sets the number of stencil bits (0 or 8). Default: 0.

--tcpSendTimeout Sets the timeout (in seconds) for the master display engine to wait for a remote display engine before giving up on a send. Default: 30 seconds.

(terrain_MTF_file | scene_MSF_file) Specifies a terrain (MTF) or scene (MSF) file to load.

--unplug filename Do not load the specified plug-in. Can be used multiple times.

--useAbsoluteTimeStamps Use absolute time stamps instead of relative time stamps.

--useFileCommChannel channel The communication file to be used as a base for communicating text

based commands from external applications.

--userDataDir directory Specifies the user data directory.

(-v | --version) Display version information and exit.

(-z | --useReverseZBuffer) Specifies use of reverse Z-buffering, which can reduce Z-fighting.

image

(-Z | --ignoreZoomForSpeedtreeLod Disable zoom for SpeedTree LOD.

HLA Only

HLA Only

(-a | --appNumber) number Application number.

image

(-f | --fomMapperLib) libname FOM Mapper library name.

(-F | --fedFileName) fedfile_name FED file name.

--fomMapperInitData data FOM Mapper initialization data.

--fomModules module Specifies a FOM Module. Can be used multiple times. (HLA Evolved only.)

(-H | --hostAddressString) address Specifies the host address.

(-i | --sessionId) ID Specifies the session ID for this instance of the front-end.

(-N | --federateName) federate_name Federate name. Default: VR-Forces. (HLA Evolved only.)

(-p | --federateType) type The federate type distinguishes different categories of federates.

--rprFomRevision RPR FOM revision.

--rprFomVersion version_number RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006, 2.0014, 2.0017, or 2.0)

(-s | --siteId ID Site ID.

--localSettingsDesignator designator Specifies a string that is passed to the RTI during federate connect. (HLA

Evolved only.)

--ignoreAdvisories Enables or disables HLA advisory messages. Default: true.

--useGeographicDdm Specifies use of geographic DDM if you are using the MÄK RTI. Default: false.

image

(-x | --execName) exec_name Execution name. Default: VR-Link.

DIS Only

DIS Only

(-a | --appNumber) number Application number.

(-A | --destAddrString) address Destination address.

--defaultObjectTimeout timeout Specifies the timeout interval for objects.

--deviceAddress address Specifies the address of the network card to use for UDP traffic.

--disVersion The DIS version. Default: 5.

(-H | --hostAddressString) address Specifies the host address. This is usually the same as the device

address.

(-i | --sessionId) ID Specifies the session ID for this instance of the front-end.

--mcastTtl Specifies the multicast time-to-live. Default: -1.

--multicastAddresses address1 ... Specifies one or more multicast addresses.

addressn

(-P | --disPort) port DIS port.

--recvBufferSize size Receive buffer size.

(-s | --siteId ID Site ID.

--sendBufferSize size Send buffer size. Default: -1.

--subnetMask mask Specifies a subnet mask.

--useAsyncIO Use asynchronous I/O. Default: False.

--useIpv6 Use the ipv6 protocol, if available.

(-x | --exerciseId) ID Exercise ID.

image

Table QR-3: Mouse Button Mappings


Navigation Action

Mouse Action

Context

Attach to entity.

Shift+left-click

Entity.

Attach to prop.

Ctrl+Shift+left-click

Prop.

Deselect all.

Left-click

Terrain or sky.

Drag terrain.

Left-click+drag

Terrain or prop.

Object selected, others unselected.

Left-click

Selected entity or prop.

Select entity or prop.

Ctrl+left-click

Unselected entity or prop.

Select object and unselect all others.

Left-click

Unselected entity or prop.

Teleport to location.

Shift+left-click

Terrain.

Teleport to prop.

Shift+left-click

Prop.

Teleport to entity.

Ctrl+Shift+left-click

Entity.

Unselect.

Ctrl+left-click

Selected entity or prop.

Display context-sensitive menu.

Right-click

Entity or prop.

3D Only

Drag the view.

Middle mouse button drag

All.

Drag heading and pitch (mouse look).

Right Drag

All.

Orbit drag.

Ctrl+left-click+drag

Terrain or prop.

Zoom in (magnification).

Ctrl+ mouse wheel forward

All.

Zoom out (magnification).

Ctrl+ mouse wheel backward

All.

Reset magnification.

Middle mouse button

All.

Move observer forward.

Mouse wheel forward

All.

Move observer back.

Mouse wheel back

All.

Move observer level observer forward.

Shift+mouse wheel forward.

All.

Move observer level observer back- ward.

Shift+mouse wheel backward.

All.

Move flashlight beam.

Right mouse button drag

All.

Expand flashlight beam.

Alt+mouse wheel forward.

All.

Contract flashlight beam.

Alt+mouse wheel backward.

All.

2D Only

Rotate terrain.

Right-click + drag

All. Orient North disabled.

2D Zoom in.

Mouse wheel forward; Middle button + drag

All.

2D Zoom out.

Mouse wheel backward; Middle button + drag

All.

K = numeric keypad (K8 means press Keypad 8). To use the numeric keypad for navigation, NumLock must be on.


Table QR-4: Observer Keyboard Mappings


Observer Movement

Observer

Level Observer

Laptop

2D Level Observer

Move forward.

w

unmapped

w

unmapped

Move back.

s

unmapped

s

unmapped

Move left.

a

unmapped

a

unmapped

Move right.

d

unmapped

d

unmapped

Move up.

q, Ctrl+q

unmapped

q, Ctrl+q

unmapped

Move down.

e, Ctrl+e

unmapped

e, Ctrl+e

unmapped

Move forward level observer.

unmapped

w

unmapped

w

Move back level observer.

unmapped

s

unmapped

s

Move left level observer.

unmapped

a

unmapped

a

Move right level observer.

unmapped

d

unmapped

d

Move up level observer.

unmapped

q, Ctrl+q

unmapped

unmapped

Move down level observer.

unmapped

e, Ctrl+e

unmapped

unmapped

Move attached context forward.

Shift+w

Shift+w

Shift+w

Shift+w

Move attached context back.

Shift+s

Shift+s

Shift+s

Shift+s

Move attached context left.

Shift+a

Shift+a

Shift+a

Shift+a

Move attached context right.

Shift+d

Shift+d

Shift+d

Shift+d

Move attached context up.

Shift+q

Shift+q

Shift+q

unmapped

Move attached context down.

Shift+e

Shift+e

Shift+e

unmapped

Level yaw left.

K 4

K 4

Left arrow

Left arrow

Level yaw right.

K 6

K 6

Right arrow

Right arrow

Level pitch up.

Shift+j

Shift+j

Shift+j

unmapped

Level pitch down.

Shift+k

Shift+k

Shift+k

unmapped

Level roll right.

Shift+i

Shift+i

Shift+i

unmapped

Level roll left.

Shift+m

Shift+m

Shift+m

unmapped

Yaw left.

Shift+h

Shift+h

Shift+h

Shift+h

Yaw right.

Shift+l

Shift+l

Shift+l

Shift+l

Pitch up.

K 8

K 8

unmapped

Pitch down.

K 2

K 2

unmapped

Roll right.

K 9

K 9

K 9

unmapped

Roll left.

K 3

K 3

K 3

unmapped

Orbit right.

Ctrl+d,

Ctrl+d,

Ctrl+d

unmapped

Orbit left.

Ctrl+a,

Ctrl+a,

Ctrl+a

unmapped

Orbit up.

Ctrl+w,

Ctrl+w,

Ctrl+w

unmapped

Orbit down.

Ctrl+s,

Ctrl+s,

Ctrl+s

unmapped

Look up.

Ctrl+K 8

Ctrl+K 8

Ctrl+K 8

Ctrl+K 8

Look down.

Ctrl+K 2

Ctrl+K 2

Ctrl+K 2

Ctrl+K 2

Look left.

Ctrl+K 4

Ctrl+K 4

Ctrl+K 4

Ctrl+K 4

Table QR-4: Observer Keyboard Mappings

Observer Movement

Observer

Level Observer

Laptop

2D Level Observer

Look right.

Ctrl+K 6

Ctrl+K 6

Ctrl+K 6

Ctrl+K 6

Look tilt left.

Ctrl+K 3

Ctrl+K 3

Ctrl+K 3

Ctrl+K 3

Look tilt right.

Ctrl+K 9

Ctrl+K 9

Ctrl+K 9

Ctrl+K 9

Zoom In

unmapped

unmapped

unmapped

Ctrl + e

Zoom Out

unmapped

unmapped

unmapped

Ctrl + q

Suppress constrain to terrain.

x

x

x

x

Water Impact

unmapped

unmapped

unmapped

unmapped

Reset observer:

Space

Space

Space

Space

In absolute mode, go to the center of the scene. If attached, reset the attach position and orientation.

Toggle Speed Scaling Mode (MSL or AGL)

unmapped

unmapped

unmapped

unmapped

Level observer.

K 5

K 5

Shift+Space+

K 5

Toggle Force North Orientation

unmapped

unmapped

unmapped

unmapped

Toggle Orient To Target Constraint

unmapped

unmapped

unmapped

unmapped

Toggle Flashlight

F

F

F

F

Reset the camera.

K 0

K 0

K 0

Increase View Magnification

=

=

=

unmapped

Decrease View Magnification

-

-

-

unmapped

Reset View Magnification

0

0

0

unmapped

Increase View Resolution

unmapped

unmapped

unmapped

=

Decrease View Resolution

unmapped

unmapped

unmapped

-

Detach.

z

z

z

z

Toggle Hide Model On Attach

unmapped

unmapped

unmapped

unmapped

Attach to the next entity allowed by the attachment filter.

Period (.)

Period (.)

Period (.)

Period (.)

Attach to next entity or prop.

>

>

>

>

Attach to the previous entity allowed by the attachment filter.

Comma (,)

Comma (,)

Comma (,)

Comma (,)

Attach to previous entity or prop.

<

<

<

<

Set Mimic Attach Type

unmapped

unmapped

unmapped

unmapped

Set Tether Attach Type

unmapped

unmapped

unmapped

unmapped

Next attach mode.

Shift+z

Shift+z

Shift+z

Shift+z

Increase linear speed.

K 7

K 7

K 7

K 7

Decrease linear speed.

K 1

K 1

K 1

K 1

Increase orbit speed.

K +

K +

K +

K +

Decrease orbit speed.

K -

K -

K -

K -

Increment Rotation Speed Gain

unmapped

unmapped

unmapped

unmapped

Table QR-4: Observer Keyboard Mappings

Observer Movement

Observer

Level Observer

Laptop

2D Level Observer

Look right.

Ctrl+K 6

Ctrl+K 6

Ctrl+K 6

Ctrl+K 6

Look tilt left.

Ctrl+K 3

Ctrl+K 3

Ctrl+K 3

Ctrl+K 3

Look tilt right.

Ctrl+K 9

Ctrl+K 9

Ctrl+K 9

Ctrl+K 9

Zoom In

unmapped

unmapped

unmapped

Ctrl + e

Zoom Out

unmapped

unmapped

unmapped

Ctrl + q

Suppress constrain to terrain.

x

x

x

x

Water Impact

unmapped

unmapped

unmapped

unmapped

Reset observer:

Space

Space

Space

Space

In absolute mode, go to the center of the scene. If attached, reset the attach position and orientation.

Toggle Speed Scaling Mode (MSL or AGL)

unmapped

unmapped

unmapped

unmapped

Level observer.

K 5

K 5

Shift+Space+

K 5

Toggle Force North Orientation

unmapped

unmapped

unmapped

unmapped

Toggle Orient To Target Constraint

unmapped

unmapped

unmapped

unmapped

Toggle Flashlight

F

F

F

F

Reset the camera.

K 0

K 0

K 0

Increase View Magnification

=

=

=

unmapped

Decrease View Magnification

-

-

-

unmapped

Reset View Magnification

0

0

0

unmapped

Increase View Resolution

unmapped

unmapped

unmapped

=

Decrease View Resolution

unmapped

unmapped

unmapped

-

Detach.

z

z

z

z

Toggle Hide Model On Attach

unmapped

unmapped

unmapped

unmapped

Attach to the next entity allowed by the attachment filter.

Period (.)

Period (.)

Period (.)

Period (.)

Attach to next entity or prop.

>

>

>

>

Attach to the previous entity allowed by the attachment filter.

Comma (,)

Comma (,)

Comma (,)

Comma (,)

Attach to previous entity or prop.

<

<

<

<

Set Mimic Attach Type

unmapped

unmapped

unmapped

unmapped

Set Tether Attach Type

unmapped

unmapped

unmapped

unmapped

Next attach mode.

Shift+z

Shift+z

Shift+z

Shift+z

Increase linear speed.

K 7

K 7

K 7

K 7

Decrease linear speed.

K 1

K 1

K 1

K 1

Increase orbit speed.

K +

K +

K +

K +

Decrease orbit speed.

K -

K -

K -

K -

Increment Rotation Speed Gain

unmapped

unmapped

unmapped

unmapped


Table QR-4: Observer Keyboard Mappings


Observer Movement

Observer

Level Observer

Laptop

2D Level Observer

Decrement Rotation Speed Gain

unmapped

unmapped

unmapped

unmapped

Toggle speed scaling on or off.

K *

K *

K *

K *

Toggle Prop Transparency

T

T

T

T

Toggle Terrain Scaling

unmapped

unmapped

unmapped

unmapped

Increment Terrain Scale

unmapped

unmapped

unmapped

unmapped

Decrement Terrain Scale

unmapped

unmapped

unmapped

unmapped

Toggle Track Histories

unmapped

unmapped

unmapped

unmapped

Toggle Entity Labels

L

L

L

L

Toggle Rotate Entity Symbols

unmapped

unmapped

unmapped

unmapped

Toggle Tactical Graphics

Shift+G

Shift+G

Shift+G

Shift+G

Toggle Entity Height Above Terrain Lines

unmapped

unmapped

unmapped

unmapped

Toggle Tactical Graphics HAT Lines

unmapped

unmapped

unmapped

unmapped

Toggle Entity Height Above Terrain Mode

unmapped

unmapped

unmapped

unmapped

Toggle Tactical Graphics Height Above Terrain Mode

unmapped

unmapped

unmapped

unmapped

Toggle constrain to terrain on or off.

/

/

/

/

Toggle Constrain To Center

U

unmapped

unmapped

unmapped

Clear the current movement mode. This key is an escape mechanism if keys are not behaving as you expect. This is typi- cally due to a loss of the window context.

c

c

c

c

Next Observer Mode

]

]

]

]

Previous Observer Mode

[

[

[

[

Toggle view controls on or off.

Shift+c

Shift+c

Shift+c

Clear All Trajectory Histories.

unmapped

unmapped

unmapped

unmapped

Toggle OSG Framerate statistics

F2

F2

F2

F2

Print OSG statistics

Shift+[

Shift+[

Shift+[

Shift+[


image

vrfLauncher Command-Line Options


Option Description

Option Description

(-B | --backend) Start vrfLauncher for the back-end only.

B-- Following --, arguments after B-- are passed only to the back-end.

(-C | --config) Open the Simulation Connections Configuration tool.

-debug Following B-- or F--, appends a d to vrfGui or vrfSim to run the debug version. (Windows only.)

(-F | --frontend) Start vrfLauncher for the front-end only.

F-- Following --, arguments after F-- are passed only to the front-end.

(-h | --help) Displays help information in a console window.

--usePredefinedConnection

connection

Specify a connection name, such as DIS localhost, so that the vrfLauncher can launch without needing to display the Simulation Connections dialog box.

(-v | --version) Displays version information.

-- Pass all arguments after this to vrfGui and vrfSim, except per B-- or F--.

image

image



image


Link - Simulate - Visualize


VRF-4.5-1-170217


150 CAMBRIDGE PARK DRIVE, 3RD FLOOR CAMBRIDGE, MA 02140 617.876.8085 www.mak.com